K66 Beta Test

Status
Not open for further replies.
Ok..last post for today to this topic :)
60.5.4 Transfer Type register (SDHC_XFERTYP)
....
The host driver shall check PRSSTAT[CDIHB] and PRSSTAT[CIHB] before writing to
this register. When PRSSTAT[CDIHB] is set, any attempt to send a command with data
by writing to this register is ignored; when PRSSTAT[CIHB] bit is set, any write to this
register is ignored.

Do you check this ? with a quick glance at the code. i coul'ndt find that - but perhaps it is there and i didn't see it..
 
Ok..last post for today to this topic :)


Do you check this ? with a quick glance at the code. i coul'ndt find that - but perhaps it is there and i didn't see it..

grep'ing the src/ code, i do find

sdhc.c: while (SDHC_PRSSTAT & (SDHC_PRSSTAT_CIHB_MASK | SDHC_PRSSTAT_CDIHB_MASK)) { };
sdhc.c: // Wait for cmd line idle // to do timeout PRSSTAT[CDIHB] and the PRSSTAT[CIHB]
sdhc.c: while ((SDHC_PRSSTAT & SDHC_PRSSTAT_CIHB_MASK) || (SDHC_PRSSTAT & SDHC_PRSSTAT_CDIHB_MASK))

As for the mbed K64, I did port a version of WMXZ's low level driver code to the mbed K64, but only did read tests and did not use uSDFS. (post #484).
I never did any kind of sector/file write tests on the K66 or the K64, and all my tests were at 120mhz -- chicken.
 
Last edited:
Code:
static DRESULT SDHC_CMD_Do(LWord xfertyp)
{

    // Card removal check preparation
    SDHC_IRQSTAT |= SDHC_IRQSTAT_CRM_MASK;

    // Wait for cmd line idle // to do timeout PRSSTAT[CDIHB] and the PRSSTAT[CIHB]
    while ((SDHC_PRSSTAT & SDHC_PRSSTAT_CIHB_MASK) || (SDHC_PRSSTAT & SDHC_PRSSTAT_CDIHB_MASK))
        { };

    SDHC_XFERTYP = xfertyp;

ok, makes sense and looks good.
 
I am honored to be part of the beta test group. Can anyone say if analogReference(EXTERNAL) works at this time? From what I am seeing it seems to always use Vcc as the reference regardless of the setting of analogReference()

I can also confirm that Paul's small USB-Host test sketch[1] indicates 480 Mbps is enabled after the reset sequence with two high-speed USB devices (memory stick and USB camera) and it stays at 12 Mbps with a full-speed device (cheap ebay "Kontron DM9601" USB-Ethernet adaptor)

[1] https://forum.pjrc.com/threads/34808-K66-Beta-Test?p=107839&viewfull=1#post107839
 
Last edited:
analogReference(EXTERNAL) should work. Like a Teensy 3.2, there is a 470 ohm pullup resistor, so you need to use a shunt type reference, or one with a push-pull output which can sink the current from the resistor.
 
I'm going to finalize 1.29 within a few days. Please let me know which things need updating?

If it turns out to be a lot of stuff that might affect Teensy 3.2, I'll probably make a fifth beta. But my goal is to finally wrap up 1.29. This beta testing will likely mean 1.30 betas will start soon. It's time to finalize 1.29 for everyone using the existing boards.
 
Last edited:
Again playing with I2C testing. Finally hacked up my own SRF08 ping functions, and I am using i2c_t3... It is now getting valid Pings... Tested first on T3.2 and now on T3.5 beta, on both Wire and Wire2. May for the fun of it running on multiple I2C Busses at same time, if I find I have another level shifter that works with I2C.

Maybe more of an i2c_t3 question, but wondering best way to handle multiple of the same objects where you have them on multiple busses. What I did was create the constructor for the class having a reference to which i2c_t3 object that object should use. Srf08 sonar1 = Srf08(SRF_01_ADDR, Wire2);

In case anyone is interested included zip file with sketch which has the code...

Edit: Found 2nd SRF08 (actually it was an SRF10). It also was setup with different I2C address, so first try was to run both of them on Wire2, which I got working

I was then able to make it work with an BSS138 FET level shifter. Had to experiment with using external resistor or not using external or...
So I put one on Wire1 and the other on Wire2 and simply updated sketch to start both and my object definitions to say which one was on which buss... Works!

New Zip Archive file.
 

Attachments

  • SRF08-160707a.zip
    2.1 KB · Views: 96
  • SRF08-160707b.zip
    2.3 KB · Views: 101
Last edited:
Who wants the 3rd ethernet board? (of beta testers listed in msg #1) As always, the magic words are "I have time to do something".

The first 2 already shipped to manitou and macaba. A 3rd board will probably be ready tomorrow or Monday. Plenty more should become available in a couple weeks.

Again, there's no usable networking software at this point, just a little test program which responds to ping.
 
I'm going to finalize 1.29 within a few days. Please let me know which things need updating?

I'm running down a regression on i2c_t3 that somehow broke the LC slave Tx mode, specifically a T3.1 master pulling data from LC slave breaks at the data direction change. Previous test didn't show it since I only checked Slave Rx mode (slave receiving data). I verified it works in v8.1 of the library, so it's something I did recently. I'll let you know when I fix it and push the new lib to github.
 
The right one is the 1.0p8, sorry for the github confusion, I keep master for legacy purposes
Got the v1.0.8 from GitHub - wired my RedBoard-YEL_PIN to my K66 and not getting anything but white backlight (and serial stats)? I tried stock SPI wiring - then moved wiring to the alternate Audio Compatible from my TFT sample?

It looks like it is setup for YEL_PIN by default? Something else I'm forgetting? Using 1.29b4 with the v1.0.8 library? Will recheck pins.
 
... I'll let you know when I fix it and push the new lib to github.
For the next random test I was considering combining test_bus with test_slave - run one master and two slaves on the K66? On Wire, Wire1, Wire2 in some order. My limited i2c understanding on the physical layer says it could with one set of pullups - but not sure if the transfer interrupts will block each other - or bypass each other?
 
The first 2 already shipped to manitou and macaba.

Thank you Paul.

manitou
Do you have a preference for bringing up a stack?
I heard mention of lwIP integration which sounds viable, and I also wouldn't mind contributing to an effort to start from scratch (copying in code snippets from MIT projects when needed).
There was also mention earlier in the thread of xxxajk's stack.

Edit:
https://en.wikipedia.org/wiki/UIP_(micro_IP) also looks interesting.
Here is an example of the main loop using UIP
Documentation
 
Last edited:
manitou
Do you have a preference for bringing up a stack?

I thought I'd start from the bottom up -- extend Paul's sketch to do some UDP for baseline benchmarking. Then from the top, figure out how to get lwIP to compile in a sketch and see how to configure for non-RTOS. I have glanced at uIP and xxxajk's stack. Do you have links to MIT stuff? I remember back in the 80s there was a small PC/DOS TCP/IP (maybe MIT), but I haven't found any info. (i've used the lwIP/RTOS on the mbed K64)

An app note for STM lwIP, non-RTOS suggestions

http://lwip.wikia.com/wiki/Porting_for_an_OS
 
manitou

Sounds like a good plan, the Kinetis SDK has an implementation of hardware drivers for lwIP, running on bare metal, so I'll be taking a look at this.
 
The 3rd ethernet board is built & working.

Anyone (who already has a K66 beta test board) want to play with it? Just say the magic words and it'll be yours!
 
extend Paul's sketch to do some UDP for baseline benchmarking.

Any chance you could benchmark simultaneous transmit & receive UDP data flow? Maybe with sequence numbers or some other data inside the packets, so you could detect packet loss?

Performance metrics are nice, but I'm really most curious to know if there's any packet loss. I recall reading some conversations, maybe from the Beaglebone devs, about issues with packet loss with RMII (but magically solved by using MII) during fast bidirectional data flows.
 
Got the v1.0.8 from GitHub - wired my RedBoard-YEL_PIN to my K66 and not getting anything but white backlight (and serial stats)? I tried stock SPI wiring - then moved wiring to the alternate Audio Compatible from my TFT sample?

It looks like it is setup for YEL_PIN by default? Something else I'm forgetting? Using 1.29b4 with the v1.0.8 library? Will recheck pins.

I just tested with T3.0, T3.2 and T3.5 (180Mhz) and works, there's no so big changes from p7, a couple of bug fixed and the K64/66 identifiers.
I have a couple of yellow pin display here, the quality of the pins is so bad that I have to clean/revive pin really often since it oxidate really fast.
 
For the next random test I was considering combining test_bus with test_slave - run one master and two slaves on the K66? On Wire, Wire1, Wire2 in some order. My limited i2c understanding on the physical layer says it could with one set of pullups - but not sure if the transfer interrupts will block each other - or bypass each other?

There should be no issue with running multibus concurrently. In fact one of my old tests was to run T3.1 in loopback (Master on Wire, Slave on Wire1). In that config the ISRs overlap all the time. There is an example on it that should work - dual_bus_master_slave. It would need to be modified for T3.5. If you choose to modify it and use appropriate defines to make it work on all multibus devices, then I can bundle that with the next release.

I found what is causing the LC slave to break, it is the same change that was posted in the i2c_t3 thread to prevent the LC from detecting STOPs directed at other slaves on the bus. This would also affect T3.5.

The most recent ISR state diagram posted in the K66 docs is different than it used to be, and the ISR is currently not structured that way. I've managed to hack the current ISR into a working state, but it really needs a rebuild (the trick is merging the diagram flow with the custom T3.0/1/2 ISR). I'm planning to rework the ISR anyway to fix ARBL, but that will probably push to a future update.

For now I've attached an update (it's still work in progress). It would be good to check this against the multibus sketch. I'd be interested to know how that turns out.

edit: just a note - in dual_bus_master_slave sketch there is a setRate() call, it may need an update to uint32_t. I would comment it out if it causes problems, it is not necessary for that sketch.
 

Attachments

  • i2c_t3.cpp
    78.3 KB · Views: 125
  • i2c_t3.h
    52.3 KB · Views: 93
Last edited:
Nox771: Should I retry my I2C stuff with SRF sonars with this? They don't do anything I2C Special, but do have one on Wire1 and another on Wire2, and today I have an I2C display arriving (https://www.amazon.com/gp/product/B00O2KDQBE)

Which I could hopefully hook up to Wire and maybe have sketch that displays the Sonars on the display...
 
I'd be interested to know if you run into problems with any multibus testing you do. I expect this will be a common usage scenario on T3.5. Regarding the slave problems, that is specific to LC and T3.5 in slave mode. Normal off-the-shelf slaves should work without problems.
 
Any chance you could benchmark simultaneous transmit & receive UDP data flow? Maybe with sequence numbers or some other data inside the packets, so you could detect packet loss?

Performance metrics are nice, but I'm really most curious to know if there's any packet loss. I recall reading some conversations, maybe from the Beaglebone devs, about issues with packet loss with RMII (but magically solved by using MII) during fast bidirectional data flows.
I usually test UDP recv loss rates with sequenced packets, though those losses are usually from the MCU being unable to keep up. I don't have a bi-directional test on the shelf, but will add it to the TODO list.
 
- I've tested PT8211 - DAC: works with K66
- 216 MHZ: Since this DAC does not need mclk, i tried to switch to F_BUS (instead F_CPU) as clock-source for I2S (completely disabled mclck) Good news first : It does not crash anymore - bad news: i can hear something, but the freqency is terribly wrong (and yes, the calculation is correct.. (ok, calculated 10 Hz off..) )

@Paul: Perhaps,we should throw an #error for I2S @ 216/240
 
Last edited:
Status
Not open for further replies.
Back
Top