K66 Beta Test

Status
Not open for further replies.
What was the ambient temp?

Desk surface beside the K66 shows 71°F, 71-74 is about normal - must be down a touch as max is now 100.9°F with colder night air brought in.

74 minutes running no signs of issues with active pings from a CMD line, and the 17K cps through 4 ports, out Serial5 - to and through 6 then 4 then 3 in 2 and out USB all in parallel.
 
@PaulStoffregen I take pin32 will be connected to a USB power switch, such as MIC2004? VBUS power on the board I have does not change, but I can add this on mine.

Yes, more or less. Pin 32 was just a convenient pin for initial testing. I actually had it controlling a FSUSB30MUX chip, again only because that was a convenient resource I happened to have from another project.

On the final boards, PTE6 will control a USB power switch. See #93 for all pinout info. The part used will be TI TPD3S014, with a 100 uF ceramic capacitor.

I actually put a 3 pad jumper config on the bottom side, similar to the one on the audio board for the I2C address. In the default state, it connects the VBUS pin to the 100 uF cap and TPD3S014 output, intended for host mode. If that's cut and the other side solder bridged, VBUS connects to a 2.2 uF capacitor and to K66 pins VREG_IN0 and USB1_VBUS, intended for device mode.
 
Paul: Again not sure if you are interested in having the user be use the 6 pins for the SDCARD, but in case you might, I did do a Pull request for CORES and SPI projects

My main intention is for those 6 pins to be dedicated to SDIO mode.

At this moment I'm swamped in bed-of-nails test fixture details. But very soon I want to integrate simple SDIO code into the SD library. Still debating how the API should work, but will likely go with some name to use with SD.begin() instead of the normal CS pin number.
 
It occurred to me late last night that perhaps the reason that the microphone works with T3.2 audio but not with K66 is the processor speed.
This morning I tried the K66 at different speeds.
@ 96MHz - works
@120Mhz - works
@144MHz - works
@168MHz - fails
@180MHz - fails
So the processor speed has something to do with it.

I'm going to try line-in sometime this morning to see if it has the same problem.

Pete
 
My main intention is for those 6 pins to be dedicated to SDIO mode.

At this moment I'm swamped in bed-of-nails test fixture details. But very soon I want to integrate simple SDIO code into the SD library. Still debating how the API should work, but will likely go with some name to use with SD.begin() instead of the normal CS pin number.
Understood, it is your baby!

Looking forward to being able to ordering some of the real boards when they are available on kickstarter!

I just looked at it as, these are 6 very useful IO pins (SPI1 with 3cs pins, Uarts, I2C), so for those projects which don't need SDcards, it might be nice to be able to use these pins.

I also think it may be easier to read internal code when the Internal pin numbers are exposed as pin numbers. Where you might see something like digitalWriteFast(PIN_USB_POWER, HIGH); Than doing the equivalent of directly manipulating PTE6 registers, knowing that it should hopefully generate the same code.

But again I understand if you do not wish to take the pull requests, all of the pins I added were under an #ifdef which in that Pull, I had enabled. Ican close them out if you wish. But I will probably keep that branch on my fork.
 
Last edited:
Line-in behaves the same way. Works at 96,120 and 144. Fails at 168 and 180MHz.

Time to dig into the library code.

Pete
 
Glad post #8 was useful. Is that 4 bus code posted as a sample? With Ethernet it looks like pins are clear for I2C[0,1,3] but I2C2 and ALT's all conflict.

Yes, there is a loopback example, which when compiled for T3.6 will use all 4 buses. It assumes they are all tied together with external pullup.
 
Updates to Serial from KurtE? I didn't test his 2 Stop bit code because I didn't want to mix 'CORES' code. In doing a wiki look for 'why 2 stop' it suggests there are use cases where port to port transfers or distance/device issues can benefit from two stop bits adding a 'bit' of buffer time - this could make or break some use cases.

Also exposing #define pins names for the SDHC pins exposes 6 pins - when not needed for SD access - could be useful at times - a blinky light debug dongle or other interface device could be handy. ( I ordered Krut's sniffer type PCB ).
 
Thanks Defragster,

Paul pulled in the Serial 2 bit stop code change last night.

As for the SDHC pins, he talked about it in #954 where he says he currently wants them as dedicated SDHC pins. I will hold on to those changes.
My order from Seeedstudio shipped Friday (DHL) so should have 10 of the adapters maybe in a few days. May have to send a few of them down to Oregon ;)
 
Last edited:
I totally missed this one! So the DMASPI library needs some work again... Paul, I'll get back to you when I can work on it. Which is not now, unfortunately.

repo: https://github.com/crteensy/DmaSpi

Updates:

  1. 20160802: library example compiles, but it actually shouldn't because I need to write a separate implementation at least for SPI2, which is not present on Teensy 3.1, 3.2 and LC.
  2. 20160802: added preliminary support for Teensy 3.5 and 3.6, but I don't have the hardware at hand. If it's really the same Kinetis K SPI, and if it's really the same Kinetis K DMA mux and controller, it should work.
  3. 20160802: DMASPI0 seems to be working: https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=111143&viewfull=1#post111143 shows the expected output from the example sketch.
  4. 20160803: Added DMASPI1 for Teensy 3.5 and 3.6, untested.
  5. 20161005
    • Teensy 3.5 still broken: funky DMA channel configuration by freescale and I don't have the board. It seems that only SPI0 will be more or less simple to implement.
    • Teensy 3.6 seems to be fine: tested SPI0 and SPI1 successfully
 
Last edited:
I totally missed this one! So the DMASPI library needs some work again... Paul, I'll get back to you when I can work on it. Which is not now, unfortunately.

Yes - I started to look at it, but have not used it so not sure if there are good examples that make use of it to try out, like a version of one of the TFT displays that use it? Or other hardware? Or test between two Teensy processors?

That is the New boards have 3 SPI ports, so would need another abstracted object for SPI2. Also not sure how your CS object works and if you always use one or not. If not, there are hard coded calls to SPI.beginTransaction and SPI.endTransaction which need to instead call SPI1. or SPI2. versions.

Christoph: probably best for you to do it, but let me know if you want me to take a crack at it.

Paul: Are there areas of testing things you think we are missing? Do you need more testing for network stuff? If so I could probably try out your beta board? Any wifi options?
 
Yes - I started to look at it, but have not used it so not sure if there are good examples that make use of it to try out, like a version of one of the TFT displays that use it? Or other hardware? Or test between two Teensy processors?
The example included with the library is just a collection of multiple loopback tests, so connecting DIN to DOUT is enough. Adding other hardware would just make the demonstration harder to replicate by others, so I never expanded it.
That is the New boards have 3 SPI ports, so would need another abstracted object for SPI2. Also not sure how your CS object works and if you always use one or not. If not, there are hard coded calls to SPI.beginTransaction and SPI.endTransaction which need to instead call SPI1. or SPI2. versions.
Adding an additional SPI for the Teensy LC wasn't too hard, so I don't think it will be much of a problem with the 3.6.

A CS object is optional, and it just serves as a kind of functor for pre- and post-transfer operations. Usually that's asserting and deasserting CS, but it may or may not do less or more than that. The library example doesn't use a CS object for all operations, but for some, to demonstrate that (that it's optional).

Anyway, I'll have a look at the current teensyduino release and see how much I can find out without having the board. First of all: what define should I be looking for in order to distinguish it from the others?
 
If you look at SPI.h in the release it has a lot of the stuff. Example to test for either of the new boards:
Code:
#if defined(__MK64FX512__) || defined(__MK66FX1M0__)

Where __MK64FX512__ will be for the 3.5 and the __MK66FX1M0__ is for the 3.6 boards we are currently testing.

So if you are not using CS objects, then my guess is that the code may not work properly on SPI1 as I believe it will call SPI.beginTransaction() and SPI.endTransaction() instead of SPI1.beginTransaction, so it may not be setting up the correct CTAR register.

When I was playing around with making a version of the ILI9341_t3 display code work for multiple SPI busses, I was running into this. At first I had code that basically did a switch for every function and go if BUSS==0 SPI.begin..., BUSS==1, SPI1.begin... Had to do this for every SPI function, so I created my own SPIn (object) where I have a pure virtual base class for SPI and then subclasses for each actual SPI object... Sort of what you you are doing, with your template class, but I am too old school to get into those modern C++ things.

Kurt
 
If you look at SPI.h in the release it has a lot of the stuff. Example to test for either of the new boards:
Code:
#if defined(__MK64FX512__) || defined(__MK66FX1M0__)

Where __MK64FX512__ will be for the 3.5 and the __MK66FX1M0__ is for the 3.6 boards we are currently testing.

Thanks! Just what I need.

So if you are not using CS objects, then my guess is that the code may not work properly on SPI1 as I believe it will call SPI.beginTransaction() and SPI.endTransaction() instead of SPI1.beginTransaction, so it may not be setting up the correct CTAR register.

Oo that's actually a huge bug in the current implementation, also for the LC. I'll look for a way to handle this correctly.
 
I updated the DMASPI library and the post above. If anyone wants to give it a try, go ahead! The example should work with SPI0 DIN connected to SPI0.DOUT, giving serial output about the progress. I don't have the board so I couldn't run *any* test. If you try it, please post any results here. Even if it's just "the board hangs and seems to be silent".
 
Last edited:
I updated the DMASPI library and the post above. If anyone wants to give it a try, go ahead! The example should work with SPI0 DIN connected to SPI0.DOUT, giving serial output about the progress. I don't have the board so I couldn't run *any* test. If you try it, please post any results here. Even if it's just "the board hangs and seems to be silent".

I synced up to your changes, I have a jumper on 11 to 12 and ran your test:
Code:
Hi!
Buffers are prepared
Time for non-DMA transfer: 226us
src and dest match

Press a key to continue

Testing src -> dest, single transfer
--------------------------------------------------
Finished DMA transfer
src and dest match
==================================================


Testing src -> discard, single transfer
--------------------------------------------------
Finished DMA transfer
last discarded value is 0x63
That appears to be correct
==================================================


Testing 0xFF dummy data -> dest, single transfer
--------------------------------------------------
Finished DMA transfer
src and dest match
==================================================


Testing multiple queued transfers
--------------------------------------------------
Finished DMA transfer
Finished DMA transfer1
src and dest match
src and dest match
==================================================


Testing pause and restart
--------------------------------------------------
Time until stopped: 220 us
Finished DMA transfer
DMA SPI appears to have stopped (this is good)
restarting
Finished DMA transfer1
src and dest match
src and dest match
==================================================


Testing src -> dest, with chip select object
--------------------------------------------------
Finished DMA transfer
src and dest match
==================================================


DMA SPI is still running
DMA SPI stopped.
 
So looks like DMA Spi is working for SPI, but so far can not define SPI1 or SPI2 with it. Currently that code is only configure for LC
 
That's correct, I wanted to see if it works for SPI0 first, because I changed the whole workings of the template. Update for the other SPIs might come tomorrow.
 
Status
Not open for further replies.
Back
Top