K66 Beta Test

Status
Not open for further replies.
KurtE - would like to see your XL sheet - is this where you got that info: 11.3.1 K66 Signal Multiplexing and Pin Assignments (pg 184 K66)?

I will be more than happy to post a copy of it. It is nothing more than taking Paul's pin table that include the signal names and then cross referencing it with signal mutlpexing table in the PDFs, which are linked to in #3.

Example: Pin 37, from Paul's table we see this is actually: signal PTC10 (C10), if you go to the main (larger) pdf to page 209, you will see the PTC10 pin defined.

Code:
C7	PTC10	ADC1_SE6b	ADC1_SE6b	PTC10	I2C1_SCL	FTM3_CH6	I2S0_RX_FS	FB_AD5/SDRAM_A13
With this I believe for this pin ALT0 is Analog, Alt1 is digital Alt2 is I2C ...

BTW KurtE: - fun again with github I think I got resolved - I forked i2c_t3 - but MASTER not the right branch for K66 . . . after removing on windows and selecting on github in my fork then re-Desktop'ing I see the right files.
Git is lots of fun :lol: I have not looked up for this git project yet
 
Paul, Do you have sort of a prioritized list of things you would like tested or converted or extended?
....
Or, should I try doing some random things, like, grab random devices, like different display, or sensors and see if they compile and appear to work...

Trying random things is really best. With a formal list, you'd probably just end up finding the same problems I'd eventually find. Trying stuff I wouldn't think of doing, or trying in ways I wouldn't is much, much better. ;)

Don't worry about whether you can fix any specific problem. Great if you can, but just finding issues and posting clear steps to reproduce the problem is by far the most valuable thing.

Recently I've been a bit absent while focusing on the ethernet and usb host stuff. I probably won't be responding to many messages for at least a few more days. Please know it's because I'm concentrating on bringing up the ethernet phy hardware and struggling to get the USB host stuff going.
 
Trying random things is really best. With a formal list, you'd probably just end up finding the same problems I'd eventually find. Trying stuff I wouldn't think of doing, or trying in ways I wouldn't is much, much better. ;)
Sounds good, will try doing some random stuff!

Recently I've been a bit absent while focusing on the ethernet and usb host stuff. I probably won't be responding to many messages for at least a few more days. Please know it's because I'm concentrating on bringing up the ethernet phy hardware and struggling to get the USB host stuff going.
I sort of assumed that you were either taking a well deserved day or two off and/or more likely concentrating on some features such as this! Any specific hardware you are expecting to support that some may wish to order?
 
4-bit SDIO vs SPI SD

Since I like to compare things, here are simple SD file IO read test results for WMXZ's 4-bit DMA SDIO vs teensy SD.h vs SdFat.h. We're reading a binary file using a single file.read(), reading 512 bytes or 2048 bytes. Tested on K66 @120mhz (SPI0 full speed, 30 mhz SPI CLK and SDIO baudrate of 40mhz) to my 8GB SanDisk (class 4) microSD.

Code:
              Times microseconds (megabits/sec)
                SdFat       uSDFS          SPI0 external SD
             4-bit SDIO  4-bit SDIO      SD.h      SdFat.h
read 512     313 (13.1)    295 (15)    456 (9.0)  492 (8.3)
read 2048    394 (41.6)    396 (41)   1882 (8.7)  967 (16.9)
The DMA SDIO and SdFat are doing multi-sector read (SD CMD18) for the 2048-byte block. Teensy SD.h is just doing multiple 512-byte SPI reads. WMXZ's SDIO lib also has the option of asynchronous DMA operation. Performance can vary with make and model of SD card.

EDIT: add SdFat SDIO tests 9/6/16
more info
https://forum.pjrc.com/threads/36737-Try-SdFat-forTeensy-3-5-3-6
https://forum.pjrc.com/threads/36331-Teensy-3-6-microSD-pins
 
Last edited:
I did a quick update to the Adafruit_ILI9341 library to support SPI1. I added an optional parameter to the constructor for buss number and then in the code checked if 1 use SPI1 else SPI...
I now have an Adafruit ILI9341 display working on SPI pins 0, 1, 20...

I put in a Pull request to Paul's version, in case you wish to take a look

Performance sort of poor:
Code:
isplay Power Mode: 0x9C
MADCTL Mode: 0x48
Pixel Format: 0x5
Image Format: 0x9C
Self Diagnostic: 0x0
Benchmark                Time (microseconds)
Screen fill              749197
Text                     42560
Lines                    407394
Horiz/Vert Lines         61428
Rectangles (outline)     39302
Rectangles (filled)      1555527
Circles (filled)         229136
Circles (outline)        177991
Triangles (outline)      129212
Triangles (filled)       511924
Rounded rects (outline)  80914
Rounded rects (filled)   1696006
Done!
As compared to ILI9341_T3 or TFT_ILI93XX which on normal SPI pins gave speeds like:
Code:
Benchmark Sketch V1.1
Benchmark                Time (microseconds)
Screen fill              224023
Text                     8851
Lines                    58376
Horiz/Vert Lines         18424
Benchmark                Time (microseconds)
Screen fill              224023
Text                     8851
Lines                    58377
Horiz/Vert Lines         18424
Rectangles (outline)     11682
Rectangles (filled)      465140
Circles (filled)         64770
Circles (outline)        51577
Triangles (outline)      14039
Triangles (filled)       150783
Rounded rects (outline)  21590
Rounded rects (filled)   505785
Done!
But the bright side is I can use SPI1 here and the other libraries you can not as there is only one distinct SPI1 CS pin exposed.
 
KurtE,
in your mods in SPI.h, should correct this? SIM_SCGC6 |= SIM_SCGC6_SPI1;//was SIM_SCGC6_SPI0

Currently working on avr_emulation.h for enabling SPI1 FIFO, still not working but at list not freeze...
 
KurtE,
in your mods in SPI.h, should correct this? SIM_SCGC6 |= SIM_SCGC6_SPI1;//was SIM_SCGC6_SPI0

Currently working on avr_emulation.h for enabling SPI1 FIFO, still not working but at list not freeze...

Only SPI0 has a 4-deep FIFO -- only 1-deep on SPI1 and SPI2
 
Hi Sumotoy, which one did I miss?

In the spi.cpp, I have:
Code:
void SPI1Class::begin()
{
	SIM_SCGC6 |= SIM_SCGC6_SPI1;
	SPI1_MCR = SPI_MCR_MDIS | SPI_MCR_HALT | SPI_MCR_PCSIS(0x1F);
	SPI1_CTAR0 = SPI_CTAR_FMSZ(7) | SPI_CTAR_PBR(0) | SPI_CTAR_BR(1) | SPI_CTAR_CSSCK(1);
	SPI1_CTAR1 = SPI_CTAR_FMSZ(15) | SPI_CTAR_PBR(0) | SPI_CTAR_BR(1) | SPI_CTAR_CSSCK(1);
	SPI1_MCR = SPI_MCR_MSTR | SPI_MCR_PCSIS(0x1F);
	SPCR1.enable_pins(); // pins managed by SPCRemulation in avr_emulation.h
}
Note: so far I don't believe that my SPI1 changes have been merged into the main PJRC branch. (Still outstanding Pull request).
You can see my changes up on github: https://github.com/kurte/spi/tree/SPI1-for-3.4/3.5

There were also changes to core for SPI1, that is in the fork/branch: https://github.com/KurtE/cores/tree/SPI1-defined
Again with outstanding Pull request.

Let me know if you find something. Again so far I have tested a couple of simple things like ILI9341 using Adafruit_ILI9341 modified library as I mentioned in #506

EDIT - Thanks sumotoy - Saw your comments and hopefully I pushed up the changes that you found
 
Last edited:
Thanks manitou, this explain my headaches of today! So the SPI1 and SPI2 should be similar to Teensy LC? At list it should be slower, have to rewrrite my testing SPI_FIFO...

Thanks KurtE, I've used your changes already for testing purposes,
Have tried to update also:

Code:
void SPI1Class::setDataMode(uint8_t dataMode)
{
    SIM_SCGC6 |= SIM_SCGC6_SPI1;//SIM_SCGC6_SPI0

    // TODO: implement with native code

    SPCR1 = (SPCR1 & ~SPI_MODE_MASK) | dataMode;
}

But this needs to replicate some SPI0 functions for SPI1 in avr_emulation.h
 
Last edited:
@NOX771/Paul - I started copy/paste on i2c_t3 :: Partial Edits to date >> https://github.com/Defragster/i2c_t3/pull/1/files?diff=split

Thanks KurtE - taught me something - reading FM p#184 table this is what I see for I2C and the table shows me this matches (edited) Post#3:
Code:
// I2C0_SCL[PTB2(p19)]  / I2C0 I2C0_SDA[PTB3(p18)]
       - Wire1: I2C1_SCL[PTC10(p37)] / I2C1 I2C1_SDA[PTC11(p38)]   >> I2C_PINS_37_38	ALT=2
       - Wire2: I2C2_SCL[PTA12(p4)]	/ I2C2 I2C2_SDA[PTA13(p3)]  >> I2C_PINS_3_4		ALT=5

Comments welcome::
> I have no idea what I did with Github - it was a fork - any checkin goes to PJRC K66 as a Pull request - made it a Patch branch ????
> My editor apparently was set to use tabs not spaces - so the diff is a replace all
 
Last edited:
Thanks KurtE, I've used your changes already for testing purposes,
Have tried to update also:

Code:
void SPI1Class::setDataMode(uint8_t dataMode)
{
    SIM_SCGC6 |= SIM_SCGC6_SPI1;//SIM_SCGC6_SPI0

    // TODO: implement with native code

    SPCR1 = (SPCR1 & ~SPI_MODE_MASK) | dataMode;
}

But this needs to replicate some SPI0 functions for SPI1 in avr_emulation.h
I was wondering about that and also noticed in header file:
Code:
	// This function is deprecated.	 New applications should use
	// beginTransaction() to configure SPI settings.
	static void setDataMode(uint8_t dataMode);
So was not sure if anyone was going through the setDataMode for new stuff.

If so, was also wondering if it really makes sense to do this in AVR emulation? are there AVR processors who have a register SPCR1? Or should we simply move the only SPCR1 stuff (setup of IO pins) out of there and put directly into spi.h/spi.cpp?

What I have done so far is to emulate how SPI1 was added for LC. But if we are really trying to emulate a maybe mythical AVR register(s) with SPI, then maybe need SPDR1 and SPSR1?
 
Thanks KurtE - taught me something - reading FM p#184 table this is what I see for I2C and the table shows me this matches (edited) Post#3:
Code:
// I2C0_SCL[PTB2(p19)]  / I2C0 I2C0_SDA[PTB3(p18)]
       - Wire1: I2C1_SCL[PTC10(p37)] / I2C1 I2C1_SDA[PTC11(p38)]   >> I2C_PINS_37_38	ALT=2
       - Wire2: I2C2_SCL[PTA12(p4)]	/ I2C2 I2C2_SDA[PTA13(p3)]  >> I2C_PINS_3_4		ALT=5
Looks good. There may be more valid combinations as well.
For example on SPI2, I believe Pin 26/Alt 5 is I2C2_SCL

And for SPI0 there are lots of combinations: PIN(ALT)
I2C0_SCL: 7(7), 16(2), 19(2), 33(5)
I2C0_SDA: 8(7), 17(2), 18(2), 34(5)

> I have no idea what I did with Github - it was a fork - any checkin goes to PJRC K66 as a Pull request - made it a Patch branch ????
> My editor apparently was set to use tabs not spaces - so the diff is a replace all
Git is fun :D - I have run into issues like this as well. So I try to look before I try to upload to git.
But what is interesting is, I forked and cloned the master (Pauls), to my machine, I then went to your fork, and downloaded zip file, I then merged your changes in, using windiff, which had no issue with any of the other lines except the ones you changed, I then looked at the changes in github for windows and again all of the lines looked fine. So I don't think it is a tab versus space issue. My guess is it might be a line ending (unix vs windows), which I believe these apps handle. Also I believe there may be git settings to handle that as well.

Edit: I pushed up a copy (new branch) up on my fork with your changes, in case you wish to see if there are any differences in actual files
 
Last edited:
Exciting news... after days of struggle reading chapters 54 & 55 and the EHCI spec, I finally got the USB1 PLL running at 480 MHz and the USB1 port is completing the port reset sequence and sending 480 Mbit/sec SOF packets to a USB memory stick! So far I can't seem to enable either EHCI schedule without errors, so much more remains to be fixed before anything useful can happen. Still, pretty exciting to see 480 Mbit/sec packets. :)

In other good news, the first ethernet test boards arrived yesterday from OSH Park. I soldered one, but haven't tried it yet. Will do so soon...
 
Looks good. There may be more valid combinations as well.
For example on SPI2, I believe Pin 26/Alt 5 is I2C2_SCL

And for SPI0 there are lots of combinations: PIN(ALT)
I2C0_SCL: 7(7), 16(2), 19(2), 33(5)
I2C0_SDA: 8(7), 17(2), 18(2), 34(5)


Git is fun :D - I have run into issues like this as well. So I try to look before I try to upload to git.
But what is interesting is, I forked and cloned the master (Pauls), to my machine, I then went to your fork, and downloaded zip file, I then merged your changes in, using windiff, which had no issue with any of the other lines except the ones you changed, I then looked at the changes in github for windows and again all of the lines looked fine. So I don't think it is a tab versus space issue. My guess is it might be a line ending (unix vs windows), which I believe these apps handle. Also I believe there may be git settings to handle that as well.

Edit: I pushed up a copy (new branch) up on my fork with your changes, in case you wish to see if there are any differences in actual files


I pulled out all the possibilities and dumped any that weren't on the primary list - indeed ALT5>PTA13_SDA & PTA12/PTA14_SDL

Thanks for the GitHub update!
 
KurtE - (github fun never ends) - I lost my changes - pulled down what I thought was your edited version and over wrote and it gave me the (v8) code not the (v?) I had in progress. Can you post your raw sources here for me? I can't get github to show anything but the diff.

My editor does have an EOL setting UNIX=LF .vs. WIN=CR/LF I changed to UNIX.
 
Sorry out of the house now. Will get back to you in a couple of hours.
But should be able to download zip file from github with current stuff. Make sure to choose the correct branch (not master)
 
I thought I was reading a book Of Edgar Allan Poe for the holidays but I think it's inevitable that I read 2Kpages K66 sub family manual...
 
Both are "tales of mystery and the macabre"

... sort of like GitHub: Kurt - both the K66 & k66 branches show the same (v8) file header - the DIFFS shown look like the changes Paul made to the prior sources - not the ones I made.

My local files were lost - but I did just get them from the web since I had not done a sync.
 
Last edited:
pretty exciting to see 480 Mbit/sec packets.
That is exciting! I'm curious if there's any working USB High Speed code examples for Kinetis K66 in the wild. A cursory search around the NXP forums found various complaints about the Kinetis K60/K70 USB documentation, but no actual working code.
 
Exciting news... after days of struggle reading chapters 54 & 55 and the EHCI spec, I finally got the USB1 PLL running at 480 MHz and the USB1 port is completing the port reset sequence and sending 480 Mbit/sec SOF packets to a USB memory stick! So far I can't seem to enable either EHCI schedule without errors, so much more remains to be fixed before anything useful can happen. Still, pretty exciting to see 480 Mbit/sec packets. :)

In other good news, the first ethernet test boards arrived yesterday from OSH Park. I soldered one, but haven't tried it yet. Will do so soon...

great news !
so at least parts of the chip can run @ 480MHz :)
i'm still trying get the I2S running with more
than 200 MHz.. it's a strange timing-problem with the busses, i think. maybe, ist simple, and there is no solution.

the good news:
it's possible to drive the ili9341 with 40..50HZ refresh-rates with dma... so.. mabye it's possible to do some video..
 
Last edited:
the good news:
it's possible to drive the ili9341 with 40..50HZ refresh-rates with dma... so.. mabye it's possible to do some video..

So you can actually do something else while sending to the screen or is that just sending to the screen and nothing else?
 
It runs completely with DMA. Two possible ways:
a) a full-Screen-Buffer in the RAM (takes most of the 256K..)
b) A line-buffer (one line 320 pixel, 16 Bit)

a) works without any running code or interrupts, just with DMA.
b) needs a routine which uptes every line "just in time" (But still transfer with DMA)

It depends on your usage-.case if a) or b) is better... the DMA slows down the teensy a little bit, but it's not much.

Edit:
I'm doing this with a C64-Emulation - i tried both ways, and both have their own pros and cons...
But - the screen-update does not take much time, and is totally handled with dma/spi. I can post some code if someone is interested.

a) is very easy to use - just start the DMA. Then write to the buffer whatever/whereever you want..it gets displayed very fast..
b) needs an interrupt..
 
Last edited:
I'm curious if there's any working USB High Speed code examples for Kinetis K66 in the wild.

I found some older code for earlier chips using external HS PHY, but nothing for the on-chip USBHS PHY.

It's tough to figure out if it's really running at 480 MHz. For quite a while I missed the note at the bottom of page 1709 which documents the "feature" that the USBHS PHY PLL ignores your setting for the crystal (and seems to run at a much slower speed which doesn't correspond to any of the 3 valid settings) unless you also set a bit in another register which is mostly for enabling overrides of a lot of setting that really look like things you probably wouldn't ever want to mess with! Or at least not unless you have a 1+ GHz bandwidth oscilloscope to view the waveforms.

A cursory search around the NXP forums found various complaints about the Kinetis K60/K70 USB documentation, but no actual working code.

Just now I fixed more issues in how I was initializing the hardware. Now it's happily running with empty schedules. Kinda strange to imagine this might (soon) be the only "working" code for the K66 USBHS on the internet:

https://github.com/PaulStoffregen/k66_usbhost/blob/master/k66_usbhost.ino
 
Last edited:
Status
Not open for further replies.
Back
Top