K66 Beta Test

[defragster]

Ahh, all those comments that need to change...

My K66 FM/docs etc are still in a folder called T_3pp . . .

Manitou - I'm running 3 pings every 9 seconds in a win_10 'dos box' wired to same switch - data size of 322 bytes - somewhere over that it fails see the return? And from WiFi Pi0 every 11 secs it does one of 332 bytes (ping avg range 6 to 21 ms). Looks good so far - using the HDW checksum of course on the last linked code - with the blink and 24 char spew reduction I sent you. Will see if it makes it morning.

That makes the Pi0 packet 360 bytes against this note:
HW_CHKSUMS // warning: breaks if pkt > 198

Didn't look where/why it breaks over 332.

[manitou]

can you do something like (?)

#define printf(x,y) sprintf(sbuf,x,y); Serial.print(sbuf);
char sbuf[50];

printf("This variable is %5.3f\n",value1);

The problem is that a .c can't call Serial.print(). For my own peeking purposes, I have used sprintf() to an external char[] , and then have my sketch.ino print the external char string.

[KurtE]

The problem is that a .c can't call Serial.print(). For my own peeking purposes, I have used sprintf() to an external char[] , and then have my sketch.ino print the external char string.

Looking through cores code, I see lots of places that have mostly commented out calls to things like:
serial_print(), which I have used to help debug some different things.

However serial_print or serial_printf, or is the code for Serial1.print(), so you have to initialize Serial1. When debugging this way, I hook up an FTDI cable to pins 0, 1...

[KurtE]

Good luck Kurt. (I suppose you saw p2169 and the figure top of page 2170?) Also you wondered about 8,9,10 bit on LPUART
* 62.4.4.1 8-bit, 9-bit and 10-bit data modes [p2180
( that is a versatile port: Programming, auto baud detect, 62.4.4.4 Single-wire operation, 62.4.5 Infrared interface )

Duff have you done a PDF find on "LPUART"? In my scan I saw it can run in low power mode:
* LPUART is enabled in Doze mode. [p2163)
* LPUART Functional when using clock source which is active in Stop and VLPS modes [p92

Just looked this Duff post #462 up : it works using the USB crystal-less clock! Had to touch a lot of the USB code and add some new registers but I have the USB working down to 4 MHz. Should I add this to post 8 Known Work Items? Or is the method for this outside the normal scope of USB init?

Thanks,

Yep, there are lots of good things part of this uart. Some of them I will probably not take advantage of (yet). Like 10 bit, as not sure how in the Arduino begin format to specify it.

I will try out the single wire code as my AX12 library makes use of it on other UARTS, but will have to special case it again. Do wish I could add support functions for Single wire into the HardwareSerial virtual functions, like I suggested in other threads, but...

Now back to working with the Uart baud rate. Now adding code to begin, to detect which mode the SIM_SOPT2 PLLFLL is in and deduce the LPUART Clock speed. For some it is fixed to 48mhz (SIM_SOPT2_IRC48SEL), For others I think it is the F_PLL speed (SIM_SOPT2_PLLFLLSEL) and for low speed it is set to ? (value 0-> MCGFLLCLK).

[KurtE]

Serial6 update: I made the changes I mentioned in above message. I believe that FLL clock is currently at F_CPU/4.

I used Logic Analyzer to verify output baud rate at speeds in MHZ of 192, 216, 180, 120, 96.

I also hooked up 3.3v FTDI breakout cable to the pins, which again are in the 2x5 pin connector by SDCard:

+5v [] () GND
TX  () ()  RX
...

Using my test program was able to echo stuff from my Arduino Terminal window, through Serial5 over the FTDI cable to a Kitty window viewing the FTDI cable, and likewise stuff I typed in KiTTy went to Debug monitor...

Still more to be done, like checking all of the format options.

Also still not sure if lines like in serial6_putchar:

LPUART0_CTRL |= LPUART_CTRL_TIE;	// enable the transmit interrupt

is safe or not, probably depends on code generated. Wondering if I need to learn how BITBAND works?

However since it appears to be at least partially working, I pushed up a new branch on my fork with all of the changes:
https://github.com/KurtE/cores/tree/T3.5-Beta-Serial6

[KurtE]

Very cool that an 'unused' SD card can make a high speed connector with an adapter to "6 extra pins (plus +5v and Gnd) and these pins include full SPI1 set of pins including 3 CS pins". Hopefully a simple adapter will get published. Ick - 5V - seems like it will need a 3.3 LDO version, and maybe a debug blinky onehorse version.

Just an FYI - I will probably have Seeedstudio make up a simple adapter for me to play with. Hope this semi picture is OK...

Would do it at OSHPark, but I don't know if offer low cost runs for boards with thickness less than .75...

Before I send it out, will probably verify pins again and change names from DAT names to probably pin names E0-E5 or if later looks like we can add the pins to the actual pin table, put their pin numbers there... Earlier version I did was smaller with 2x4 connector, but no room for text... Not sure which way is better.

[PaulStoffregen]

Here's a status update...

The first 6 layer prototype PCBs were ordered today. It's a 1 week turn, and our assembly vendor is saying 1-2 weeks to build them, so we should have boards in the 2nd or 3rd week of August.

If these boards work, they'll become the round 3 betas. I'm going to launch a Kickstarter to allow everyone not on the beta test list to join in as early as possible. As soon as the Kickstarter page is live, photos will become ok to post. Of course we'll order production PCBs as soon as the prototype is fully verified. I'm *not* going to hold up any part of the production process waiting for Kickstarter, and I'll probably set a fairly short deadline on Kickstarter so it'll be closed and (hopefully) funded around time the final production boards are ready to ship.

If these first boards don't work or have any issue that requires significantly changing the PCB design, I'll do another prototype run. Each extra prototype build sets everything back about 3 weeks.

The production boards have a 3 week turn time, and production assembly takes 3-4 weeks. So if this first prototype works, realistically we ought to have a final release in early October. If I've made any mistakes on the PCB which require another prototype run, things could easily slip to November.


I'm really leaning towards renaming the K66 to "Teensy 3.6" and the K64 to "Teensy 3.5". Yes, some code comments need to be updated.

[defragster]

Here's a status update...
I'm going to launch a Kickstarter to allow everyone not on the beta test list to join in as early as possible. ... I'll probably set a fairly short deadline on Kickstarter so it'll be closed and (hopefully) funded around time the final production boards are ready to ship.
... realistically we ought to have a final release in early October.I'm really leaning towards renaming the K66 to "Teensy 3.6" and the K64 to "Teensy 3.5". Yes, some code comments need to be updated.

That looks Good! Sign me up for the Bulk pack - Great name Teensy 3.0 was only 12 days in the stone ages of 2012- ~3,500+ boards great for bulk run! Kickstarter end of August with good early August results? - busy month ahead! The T_3.5 (K64) will end up being some weeks behind that or are you hoping to co-ship that because of the common design? Maybe the low voltage delicate but strong T_3.6 should come in the color of the Anouk Edition?

I had A few of Franks boards made here - but this is still too thick is seems as it will not go in the micro slot unless the top insert end were sanded down - https://pcbs.io/ Board Thickness 1.2mm (0.0472in) ± 10% :: $4.00 per sq in for 4 copies. Kurt - if you show a BRD(gerber) file I'll order a set.

Ethernet update - messages processed in 6.5 hours :: rxcnt 59729 txcnt 9410 : 153 rx per min, with the tx response to pings 2.95 per second and still running. Speed 240 MHz, high spot temp 100.6°F
* Wired PC response typical avg 0ms - 1 in 20 groups of 3 (each 9 secs) show one of 1-3 or rarer 15 ms response times.
* WiFi Pi0 Pings 11 second repeating, size 352 bytes (380 total): None lost, Count=1616 (5hrs?), Min=2.38 ms, Max=1130, Avg 25.5, 23 over 500 ms, 166 under 6 ms. Taking out the top 23 the average is 13.24 ms over my WiFi.
(8 hour Ethernet message count now running at:: rxcnt 75167 txcnt 11845)

[Ben]

Before I send it out, will probably verify pins again and change names from DAT names to probably pin names E0-E5 or if later looks like we can add the pins to the actual pin table, put their pin numbers there... Earlier version I did was smaller with 2x4 connector, but no room for text... Not sure which way is better.

Some µSD slots have this push-to-remove mechanic (I don't know if the Teensy has/will have). Does the left part of the PCB have enough clearance to push it in the required mm or so to actuate this eject-mechanism? And: Would be great if the pins of the adapter line up with the 100 mil grid the other teensy pins are aligned with.

[KurtE]

I'm going to launch a Kickstarter to allow everyone not on the beta test list to join in as early as possible. As soon as the Kickstarter page is live, photos will become ok to post. Of course we'll order production PCBs as soon as the prototype is fully verified.

Sounds great! Will be looking for the kickstarter and order some. Would be nice to get a production type one to build a breakout board for. Should we start editing names for boards yet?

On the Ethernet shield, If you need some more people beating on it, great, I am more interested in trying it out once some of the basics are working and we can try out higher level stuff (TCP/UDP...)

Ben/Defragster: as for push to remove, I hope I left enough room, but will find out. And aligning the holes, may take until we have production boards as I don't know exactly where the slot will be on the production board. As for ordering a set, it is my understanding that the boards need to be <= .75mm,
so the 1.2mm won't work. As I mentioned I will probably order from: https://www.seeedstudio.com/fusion_pcb.html
Here you can order .6mm (or .8mm which may not work)...

[manitou]

K66 Ethernet lwIP UDP
I have UDP working with lwIP. The no-RTOS API requires polling and callbacks, so it is a little awkward, but faster than the mbed K64F with lwIP+RTOS.

results on post #686

[defragster]

K66 Ethernet lwIP UDP
I have UDP working with lwIP. The no-RTOS API requires polling and callbacks, so it is a little awkward, but faster than the mbed K64F with lwIP+RTOS.

Interesting - I'm thinking this may be an excuse to break out an ESP-8266 and pile it on. With a working sketch on the ESP I should be able to send some known coordinated stuff between the two as you update your sketch. Feel free to share any links you have to provide reference details - otherwise I'll be reading on WIKI and looking for examples. I didn't get the etherraw NTP to process, but I've got a NTP aware ESP library and I found one that can send PING.

[manitou]

Interesting - I'm thinking this may be an excuse to break out an ESP-8266 and pile it on. With a working sketch on the ESP I should be able to send some known coordinated stuff between the two as you update your sketch. Feel free to share any links you have to provide reference details - otherwise I'll be reading on WIKI and looking for examples. I didn't get the etherraw NTP to process, but I've got a NTP aware ESP library and I found one that can send PING.

Your NTP host needs to be on your local net because the etherraw sketch doesn't have the logic to route through the gateway.

My lwIP build is using a hacked teensy3 Makefile and building on a linux host. I'll do TCP next, then tidy things up a bit and push it out to github.

With the polling framework (your sketch needs to keep checking if ether frames have arrived and let the various lwIP timers do their thing), one shouldn't have big delays, so it will take some care to integrate lwIP with other teensy3 tasks...

[KurtE]

manitou: Sounds like you are having some pretty good luck.

Paul (and others): On Serial6 stuff, just pushed up a minor change to my fork/branch I mentioned earlier, where I believe I now update the TIE/TCIE flags hopefully correctly using BITBAND.

That is I copied a couple of defines (renamed a couple).

#define GPIO_BITBAND_ADDR(reg, bit) (((uint32_t)&(reg) - 0x40000000) * 32 + (bit) * 4 + 0x42000000)
#define GPIO_BITBAND_PTR(reg, bit) ((uint32_t *)GPIO_BITBAND_ADDR((reg), (bit)))
#define BITBAND_SET_BIT(reg, bit) (*GPIO_BITBAND_PTR((reg), (bit)) = 1)
#define BITBAND_CLR_BIT(reg, bit) (*GPIO_BITBAND_PTR((reg), (bit)) = 0)
#define TCIE_BIT 22
#define TIE_BIT  23

And for example in the putchar function, I now do it like:

	//LPUART0_CTRL |= LPUART_CTRL_TIE;	// enable the transmit interrupt
	BITBAND_SET_BIT(LPUART0_CTRL, TIE_BIT);

The commented out line was what I was doing earlier. Is this the correct direction to go? Should we move these level of macros out of here and pins_teensy.c into some header.

I did rebuild a test program with these changes and it still runs.

[KurtE]

For those who may be interested, I did update my SD breakout board a little. In particular the Text, which shows Pin NAMES E0-E5.

Note: I went ahead and ordered a set of 10 of them from Seeedstudio for $9.90 plus shipping.
I also uploaded the Diptrace design files up to github as well as the zip file with gerbers and like that I uploaded to Seeedstudio.
https://github.com/KurtE/Teensy3.1-B...icrosd-Adapter

Again Warning: WIP - First fabrication, never been tested...

Note: on the Bottom I show wishful thinking and it shows Pin numbers 58-63.
On my machine I also have modified versions of of core_pins.h and pins_teensy.c which under #ifdef actually makes them real pins. Not sure if anyone would be interested, but I may upload these changes to github, probably separate from the Serial6 stuff.

[WMXZ]

this gives me some more time to learn the handling of a stuck protocol.

For the records:
it is indeed possible that communication between boottloader chip and K66 get stuck.
without going into detail of the decoded (presumed SWD) protocol (Paul has a copy of the data), I can clearly see, that after some successful programming, the communication enters into a infinite loop.
This way, the system becomes non-responsive to the USB enumeration and connection PC to T3.6 beta fails.

Interestingly, on power-up, T3.6 beta does not run a program, but enters, what I think could be called 'waiting for programming' mode (regular pulses on RST line)
This may be due to the already blanked flash memory
Upon pressing prog button, programming of the K66 can be observed until the mentioned infinite loop occurs.

I have no idea if all data are transferred, but I can see the PJRC VID/PID sequence in the transferred data.
I do not know if there is a way out of this loop, but it may be that Paul (if he finds time) recognizes in the protocol listing in his hands why the infinite loop happens and what the cure might be.

[defragster]

... This may be due to the already blanked flash memory
Upon pressing prog button, programming of the K66 can be observed until the mentioned infinite loop occurs. ...

As noted my K66 got programming interrupted - can't say how for sure at this time - but whatever state I hit is was 'offline' for my purposes. It was running a sketch fine AFAIK - in the process of an upload I tapped reset or hit the power possibly - probably it was one of the times I hit TYQT GUI reset which doesn't do a clean reset when TeenyDuino is active - but went into auto program which I didn't want so I interrupted it?

In any case - I looked at it - and it was busily ignoring me - did a few power ons with button press - maybe power off with button to drain the caps - powered holding button a few extra seconds - released and it seemed that was the time TeensyDuino was out of Auto Mode, I tapped that and TeensyDuino sprang to life and got it programmed?

So if it was an infinite loop I worked around it in some repetition of those steps - but not after an uncomfortable minute or two. Apparently my blanking was left in a slightly altered state - or I found the magic recovery steps in my panic.

Paul - there a second LED by the debug port - does that offer any diagnostic value?

manitou's sketch was still watching my net broadcast traffic - getting pinged from DOS box, I stopped the rPi0 pings a bit ago doing some commands - wondering about turning it on as a local NTP server - all the web links I find expect me to be hooking up a GPS as I do that. I checked my router and it doesn't offer to be a time server, but it did do some pings it said were typically just over 0.5ms. I'll read the ESP webserver sketch and see how it does NTP requests - maybe I'll learn something.
Totals running 21 hours: rxcnt 203543 txcnt 31318 - temp no issue on my board - with the loads I've used. Somebody reported instability and 'high' temps.

Updated post 8 with notes I've gotten - this is the latest:
UHS30 :: Teensey K66 and USB Host Library version 3.0. [ EXTERMELY ALPHA! ]

FrankB has been quiet - he did some speed related stuff already in 1.29 - was there anything else - audio tips? I know he did some SD card stuff I didn't find/use/link. Anything else evolving out there, or simple samples? Usage of the full size USB adapter Erin soldered on B1/B2 boards?

[MuShoo]

Well, looks like I'm rather late to this party! I haven't read through the thread yet, but definitely interested to get one of the round 3 boards! I'll probably try and do some weird MIDI things with it, specifically seeing how easily I can port over my multi-port MIDI stuff, that kind of thing. Probably also some touch sensor stuff?

Then again, I might go a completely different route and play with robots.

[defragster]

... I haven't read through the thread yet, but definitely interested ...

As you look PM me if you see anything interesting and I'll put a link in the Post 8 summary so you and others can find it again when the next round ships.

[defragster]

I opened a new "80 MB/s" Sandisk XC1 64GB microSDXC card and plugged it in - it is formatted ExFat and ran SDHC_TEST 72-75 MB/s (non-FAT fails uSDFS_test). Using the latest library github linked from the post_8 just updated.

uSDFS :: ported ELM-CHaN's FATFS to K66 as Teensy library (with GitHub link) Post w/details

I went to a smaller Sandisk HC1 32GB card microSDXC - formatted Fat32, speed is less than HALF - but it ran the uSDFS_test and created the file, removed - scanned fine on PC - added files - renamed HELLO10.TXT, repeated test and scan on PC - All Good.

My IDE was set at 240 MHz - it completed the SDHC_test - I commented the loop() { //return} and I get this with 60 MHz F_BUS:

SDHC_TEST
0 80000000

use DMA? 1

Partitions
Start Size
32768 122208256
0 0
0 0
0 0
BLKATTR: 40200
...
10000000: 0.905230 s; 4.524817 Mbaud
10001000: 0.054950 s; 74.540489 Mbaud
10002000: 0.054569 s; 75.060928 Mbaud
...
12839000: 0.054647 s; 74.953796 Mbaud
...
16409000: 0.054594 s; 75.026558 Mbaud
...
17835000: 0.056509 s; 72.484032 Mbaud
...

>> 32GB FAT32 card - ( F_BUS at 60 and this at 120 MHz)

SDHC_TEST
0 80000000

use DMA? 1

Partitions
Start Size
2048 62331904
0 0
0 0
0 0
BLKATTR: 40200
...
10000000: 0.917591 s; 4.463862 Mbaud
10001000: 0.134463 s; 30.461912 Mbaud
10002000: 0.134227 s; 30.515471 Mbaud
...

[WMXZ]

I opened a new "80 MB/s" Sandisk XC1 64GB microSDXC card and plugged it in - it is formatted ExFat and ran SDHC_TEST 72-75 MB/s (non-FAT fails uSDFS_test). Using the latest library github linked from the post_8 just updated.

uSDFS :: ported ELM-CHaN's FATFS to K66 as Teensy library (with GitHub link) Post w/details

I went to a smaller Sandisk HC1 32GB card microSDXC - formatted Fat32, speed is less than HALF - but it ran the uSDFS_test and created the file, removed - scanned fine on PC - added files - renamed HELLO10.TXT, repeated test and scan on PC - All Good.

My IDE was set at 240 MHz - it completed the SDHC_test - I commented the loop() { //return} and I get this with 60 MHz F_BUS:



>> 32GB FAT32 card - ( F_BUS at 60 and this at 120 MHz)

exFat is possible but must be configured in ffconf.h (needs also lfn)
I found it sometimes useful with brand new 'camera' uSD's to simply reformat with PC

(Caveat: have no working K66, so my help is limited)

[KurtE]

Using SDCard pins as real pins:

I thought I would put this to bed for a bit as I play more with the Serial6 code. But decided to first upload my my updated bits and pieces and I now have it setup, that the pins are setup with real (OPTIONAL) pin numbers (E0-E5) are (58-63). As part of this I updated my ILI9341_t3n graphic test program to use these pins instead of my hacks 0xe0-0xe3. Also with this I now can do things like: pinMode(58, OUTPUT)... All pieces are now up on my github

CORE: https://github.com/KurtE/cores/tree/T35_USE_SDCARD_PINS
SPI: https://github.com/KurtE/SPI/tree/T35_USE_SDCARD_PINS
SPIN: https://github.com/KurtE/SPIN
ILI9341_t3n: https://github.com/KurtE/ILI9341_t3n/

The hacked up graphic test program is an example under the ILI9341_t3n library. Note: I only updated graphictest... May play with others later.

Now back to Serial6... Trying to understand the format stuff...

[PaulStoffregen]

For the records:
it is indeed possible that communication between boottloader chip and K66 get stuck.
without going into detail of the decoded (presumed SWD) protocol (Paul has a copy of the data)....

There may indeed be a bug. That's why I really want you to send that board back to me. Please try harder. The unpleasant reality is your local post office may never cooperate. You might need to contact a carrier like DHL. Sending a package to the USA is not impossible. I'm sure you can do it.

I do have the emails you sent a couple days ago. Haven't looked at them yet. Likewise for many others and forum threads, while I was working on finalizing the PCB design over the last 2 weeks. This weekend I'm trying to get caught up.

But the simple reality is staring at logic analyzer plots is a terribly inefficient way to troubleshoot this problem, especially remotely. I have much better tools here. But I need you to send that board back to me.

We will build and send you another board just as soon as it arrives. Please, get on this, so I can work on really resolving this problem in a time-efficient manner. I have a tremendous number of other urgent tasks, and I really do want to get to the bottom of this, so I really need to get it here so I can work on it directly. I just can't spend a lot of extra time going back and forth over hard-to-use logic analyzer plots.

[WMXZ]

There may indeed be a bug. That's why I really want you to send that board back to me. Please try harder. The unpleasant reality is your local post office may never cooperate. You might need to contact a carrier like DHL. Sending a package to the USA is not impossible. I'm sure you can do it.

Sure, it can be done. As soon as I'm in Germany for a couple of days, I will send by another courier. (actually so far, it was UPS with return label from Robin; I never had any problems importing with UPS but exporting from Italy seems somewhat convoluted, independent of carrier).

BTW, the reason why I sent you the LA logs, especially the last one (excel file), is that you have the facts early on your table so you can have a first look and assess the severity.
I agree, the plots are only for demonstration and not useful for debugging.

[manitou]

K66 ethernet lwIP TCP
I got TCP client and server working on K66. Blasting TCP packets from linux to K66, the receive rate is 51 mbs (faster than mbed K64F with lwIP+RTOS). Alas, blasting TCP packets from K66 to linux achieved less than 1 mbs??? So some tuning/configuration required... Default TCP window size is 2*1460, not really an issue for local ether tests.

more info in post #686

fyi, here is a tcptrace of k66 TCP sending 100 1000-byte packets as measured by tcpdump on the receiving host, there are some large pauses: 250ms between SYN-ACK and first data packet, then some 500ms pauses ?? The lwIP fast timer for TCP is 250ms, and the slow timer period is 500ms.

The instantaneous bandwidth has peaks at 24mbs. The data rate for sloping sequence is 1000 bytes/ 40 ms or 0.2mbs

EDIT:
I reduced the TCP fast timer to 50ms, and doubled the window-size to 4*1460, here is the resulting TCP trace

The delay after the SYN-ACK was only 48ms. The data rate for the 100 1000-byte tcp_write()s was 1.4 mbs, but the initial spike was 52 mbs, and the latter steps were 4*1000 bytes every 40ms (0.8 mbs). I can't yet explain the 40 ms delays.

EDIT 2:
The 40 ms delay was actually delayed-ACK on the linux side, induced by the way I was doing tcp_write() on the k66. With tcp_write loop fixed, i get the following TCPtrace

There is the unexplained initial pause of 100ms after SYN-ACK, and the resulting data rate is 6.6 mbs. if you discount the 100ms pause, the data rate is 38 mbs.

EDIT 3:
Adding tcp_output() to tcp_write loop fixed initial pause. TCP send data rate is 59 mbs.