K66 Beta Test

Status
Not open for further replies.
And I just did a github Sync - still not propagated yet I suppose if you updated that. It must be much more fun having help testing and coding and not working alone as others get to enjoy and participate in your work!

I just RE-confirmed my two SPI displays work ILI9341 (including Touch) and the ILI9163C. Frank made a display board I soldered up to work on either like the purple PJRC OSH board (with 16MB ParFlash not ready for K66 yet). The T_3.5 at 240 Mhz is about double the 96 MHz T_3.2 - even with SPI as the bottleneck.

Is there an updated copy of Boards.Txt - mine seems to be broken - maybe my platform.txt got messed up. Hopefully 1.29b3 is stable enough to drop soon. I was compare testing with display on a T_3.2 and fired up TYQT to get a second SerMon, and knowing better I made it mess up my files - and the undo isn't ready for what it found it seems. With only 1 active Teensy the IDE SerMon has been working well.

KurtE - thanks for the GitHub tips - one thing hit me right away - FORK versus CLONE - I had a forked copy.

Manitou - thanks for the pointer to the RTC_isr - that kept me busy for hours - it works fine proving the clock is stable - tick counter seems off a few low us per second per elapsedMicros() (I re-wrote your isr() to set one each second to cause the update). Still puzzled why it doesn't start near zero ppm error after it is normalized up front? And a couple us is only a couple ppm but it starts way high (100K?) and then averages down over time as ticks grows, until us rolls over.

With PJRC Audio card functional I suppose I'll hook that up and go through the Tutorial code before soldering another Prop_LC since my first one is abnormally hot just getting power from a T_3.2 with pin 5 high for 15 seconds.
 
At this moment, patching i2c_t3 and FastLED are the last 2 things on my list before 1.29-beta3. I also want to quickly retest some stuff on Teensy 3.2 & LC, since quite a lot of code has been touched recently.

Here's the board.txt I've been using.
 

Attachments

  • boards.txt
    45.7 KB · Views: 167
Last edited:
I've added some code to (hopefully) make F_BUS overclocking easier. Now you can just uncomment lines in kinetis.h to select a different F_BUS option.

There's also a check to allow specifying F_BUS from the command line, which should allow creating options in boards.txt to appear in Arduino's menus. Whether that ever becomes part of the official Teensyduino installer will depend on feedback about F_BUS overclocking. This affects a *lot* of peripherals, so just because something like hardware serial works doesn't necessarily mean SPI, I2C, I2S, touch sense, timers, and other stuff will work. Much testing needed. Hopefully this will at least make things easier to try faster F_BUS speeds.
 
FastLED: Fixed #ifdef...) Not sure where to try to merge in changes

I sync'd to the latest FastLED, and then added the #ifdefs you described in #209. It allows FastLED to compile, but I haven't tested. Is that enough for 1.29-beta3, or were other edits to FastLED needed?
 
Personally I think it is good enough for Beta3. The only test I did was to run the test program that is part of the propshield product page and it worked with this change.
 
Manitou - thanks for the pointer to the RTC_isr - that kept me busy for hours - it works fine proving the clock is stable - tick counter seems off a few low us per second per elapsedMicros() (I re-wrote your isr() to set one each second to cause the update). Still puzzled why it doesn't start near zero ppm error after it is normalized up front? And a couple us is only a couple ppm but it starts way high (100K?) and then averages down over time as ticks grows, until us rolls over.
You need to set the base times for each clock on the first interrupt, but not do a ppm calc on the first interrupt, that should reduce the startup error. The longer the cumulative drift is calculated, the more accurate the estimate.

of course, measuring against the MCU crystal may not be that accurate, since it has its own drift value. Measuring against a GPS pps or NTP host would be best. (voltage, temperature, age, capacitance can effect drift. constatin has lots of posts on measuring drift and compensating for temperature)
 
It must be much more fun having help testing and coding and not working alone as others get to enjoy and participate in your work!

Yes, this beta testing definitely helps! Robin & I also want to give you guys who contribute so much early access to the nice new hardware too. ;)

Admittedly this started out a little rough. Hopefully 1.29-beta3 lets us all move forward on a much more solid foundation of mostly-working code.
 
Yes, this beta testing definitely helps! Robin & I also want to give you guys who contribute so much early access to the nice new hardware too. ;)

Admittedly this started out a little rough. Hopefully 1.29-beta3 lets us all move forward on a much more solid foundation of mostly-working code.
Thanks!

Personally I think it is amazing how quickly you are able to turn around things here. My guess is already you have more things working than what was working with the Arduino Due many months after it was released.
 
Ok, now I have this issue.
On Win7/64 from yesterday the K66 continue asking:
"Teensy did not respond to a USB-based request to automatically reboot.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch."
Tryed upload blink.ino, changed port, disinstalled driver, no matter what I'm trying to do, it keep asking this (and serial port don't open).
The serial port is present on Port menu.
Switch to another computer with Win10, same software, same core (last one), no problem. So I upped the blink on win10, then switch to win7, tried upping something... again "Teensy did not respond to a USB-based request to automatically....bla bla".
Even weird, remain stuck between restarts!
I will try now to completely remove the driver and reinstall again...
 
Last edited:
I've added some code to (hopefully) make F_BUS overclocking easier. Now you can just uncomment lines in kinetis.h to select a different F_BUS option.

There's also a check to allow specifying F_BUS from the command line, which should allow creating options in boards.txt to appear in Arduino's menus. Whether that ever becomes part of the official Teensyduino installer will depend on feedback about F_BUS overclocking. This affects a *lot* of peripherals, so just because something like hardware serial works doesn't necessarily mean SPI, I2C, I2S, touch sense, timers, and other stuff will work. Much testing needed. Hopefully this will at least make things easier to try faster F_BUS speeds.

Awesome :)
 
About serial hangs....
Remove driver and reinstall not works, looks like the port is stuck and remain stuck between restarts.
I got the same problem on a second laptop, win7/64 as well, happened an hour ago.
To get it back I have completely reset all serial ports on both computers.
Weird, never happened with Teensy 3.2!
 
Last edited:
Hi Paul, tried it. Is this correct ?

Edited the line in boards.txt:

Code:
teensy35.menu.speed.240opt.build.fcpu=240000000 -DF_BUS=60000000

Output looks like:
Code:
"C:\arduino-1.6.9\hardware\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w  -g -Wall -ffunction-sections -fdata-sections -nostdlib -fno-exceptions -felide-constructors -std=gnu++0x -fno-rtti -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -D__MK66FX1M0__ -DTEENSYDUINO=129 -DARDUINO=10609 -DF_CPU=240000000 -DF_BUS=60000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\arduino-1.6.9\hardware\teensy\avr\cores\teensy3" "-IC:\arduino-1.6.9\hardware\teensy\avr\libraries\SPI" "f:\buildc48d5c21c7c3d462900b6d734cfb390a.tmp\sketch\ILI9341_fire_K66.ino.cpp" -o "nul"
..looks ok for me. Is it ?

But no change..seems not to work.

Edit: Nevermind...should have used -DFBUS=120000000 :)
 
Last edited:
running beta3 and new boards.txt :
touch now works but
can anyone else confirm that ADC for pins A14 and up appear to be floating whatever voltage you put on those pins?
I also get nonsense now for the VREF and temperature (45,44).
 
running beta3 and new boards.txt :
touch now works but
can anyone else confirm that ADC for pins A14 and up appear to be floating whatever voltage you put on those pins?
I also get nonsense now for the VREF and temperature (45,44).

I installed 1.29 beta3 on 1.6.7 and new boards.txt on ubuntu 14.04
all ADC pins look good

temp sensor (44) looks reasonable (use DEFAULT reference), my centrigrade equation c = -0.0213*a + 330;

VREF output (45) still misbehaves (as it did on mbed K64), returning 7648mv from mv = 1195 * 4096 /analogRead(45)
I've also tried VREF_SC |= VREF_SC_VREFEN; -- didn't help
(post #284 i substituted bandgap sucessfully)

EDIT: RESOLVED :)
you need VREF_SC |= VREF_SC_VREFEN | VREF_SC_MODE_LV(1);
(attn: Paul teensy 3.1 also has that register, but it seems to be set 0xE1 in analog.c )
 
Last edited:
The ADC-library does not compile, because there is an #define for mk66/mk64 missing - maybe more, but i could'nt test it.
 
Status
Not open for further replies.
Back
Top