K66 Beta Test

[WMXZ]

next TODO: remove locked wait for DINT but use sdhc_isr for asynchron sdhc access.

Done!
The sdhc SW can now be compiled to use ISR to signal completion of SDHC-DMA transfer.

This way, async processing is possible.
(not sure if it is needed (at least for read) as transfer is really fast)

Edit: disturbing debug print is now removed

 

[manitou]

Wow, CPU @120mhz (baud 40mhz) with my 8GB SansDisk microSD, single sector DMA data rate 19.2 megabits/sec.
5-sector DMA data rate 300 mbs!
i'll instrument it and look with analyzer. (from my earlier posts using hacked BRTOS version got 14.2 mbs for single sector with FIFO, a lot of time was being lost waiting on DLA from card, but with analyzer, the transfer rate was close to 400mbs. i didn't believe or understand that, but maybe it's true)

OK, with analyzer and toggling pin in driver, I get different behavior from my analysis of earlier BRTOS tests, and I don't see 300 mbs. So I need to study further.
Here is what analyzer saw. for 1-sector read micros() reports 280us, analyzer shows DLA wait of 4.6us and transfer time of 274.6us, for 14.6mbs. I actually did a "primer" sector read first (which analyzer shows taking 620us). A COUNT 4 (5 sector?) read, micros() says 408us, analyzer shows DLA wait of 4.7us, transfer time of 402.6 us, or about 50.8 mbs. If i increment the sector by 5 on each read, subsequent reads are taking 283us (72 mbs).

and in the free running loop section, analyzer is showing 333us transfer time per 5-sectors (61.5mbs)

EDIT: i think your baudrate is off by a factor of 5. you already have sector count you don't need to multiply by 5,
so 300mbs becomes 60mbs, closer to what analyzer was seeing

 

[KurtE]

Did a little more Serial Testing...
In particular testing for:

Serial1.transmitterEnable(pin)
Serial2.transmitterEnable(pin)
Serial3.transmitterEnable(pin)
Serial4.transmitterEnable(pin)
Serial5.transmitterEnable(pin)

To do this I partially assembled one of my earlier boards that was using a SN74LS241DWR chip as a UART direction chip . I soldered one of these on the board as well as CAP, plus PU resistor and enough break out pins, such that the RX/TX and Direction pin were there plus GND/+3.3v/+5v. So I could then jumper this signals over from the T3.5 board, which I first hooked up
For Serial0 (0, 1) and then compiled my AX-12 test program, which uses my Bioloid library.

I verified I could talk to two servos, then reconfigured for Serial2, moved jumpers from 0,1 to 9, 10, tested again, then ...
So I was able to verify I could use the transmitter pin on Serial1-5 and works at 1mbs baud rate.

As for Serial6? I don't think it exists yet? I believe it is on the maybe iffy pads on bottom of T3.5? Also I believe that if it does exist it is not the same as the other UARTS? but instead an LPUART (Chapter 62?)

 

[WMXZ]

EDIT: i think your baudrate is off by a factor of 5. you already have sector count you don't need to multiply by 5,
so 300mbs becomes 60mbs, closer to what analyzer was seeing

You are right, and I already changed code
Sorry about that.
however, 93 Mbaud for 80Mhz SDHC clock is not bad (on my black 128 gig class 10 ScanDisk)

 

[Frank B]

If you're writing a library -please support long filenames

 

[PaulStoffregen]

Mine is PROTO5, that explains it! I though I had gone crazy...

Opps, sorry about that. There were only a couple version 5 boards. They just got mixed in, without any way of tracking who got which version... and of course we ended up with bad luck that a version 5 went to the one person who really needs access to all the analog pins!

If you'd like, we can swap it for a version 6 board next week.

I believe we're down to just nine round 2 boards left, with 7 of them not yet soldered. I just checked and all 9 of them are version 6. If we're going to swap it so you can access those 3 pins, now's the time!

 

[PaulStoffregen]

Not sure if this already been asked, USB0 or USB1 in the final version?

Both. USB0 routes to the USB device connector - same as every other Teensy.

USB1 will route to a location to solder a 5 pin header, as described in msg #93 with the pinouts. If you solder a 5 pin header, you can plug in a cable like this:

http://www.frontx.com/pro/p1012_030.html

Of course, these are very standard internal PC cables. Some use only 4 pins, and some have a pair of USB to 10 pins. All should work if the line the pins up correctly.

 

[defragster]

Did a little more Serial Testing...

KurtE - got Serial 1-5 working and has added Serial6 : Serial6 update

I extended my function test with serial 'Loop Through' - works up to 3,000,000 baud. With wiring serial PORT to PORT :: pins>1-34,33-31,32-7,8-9

Starting the sketch shows the alphabet with a new char looping through every 700ms. With a qBlink toggle on each print. And shows millis() at the end of the alphabet.

Input from USB goes out Serial1, Serial1 to Serial5 where it is parsed as it arrives, unparsed characters are echoed. Characters parsed are: "ENTER:: 's' slow blink, 'f' fast blink, 't' TURBO blink, 'c' CPU Specs, 'w' pad '~', '?' help".

Enter 't' goes to turbo mode with waits of 50ms and drops to 6ms on successive t's. I limited to 6ms as the cascade timing messes up USB display. Enter 'w' prints '~' (up to 20 times) padded between alpha characters. Worst case net throughput only 3600 characters per second? But lots of looping and it works.

Those chars write out Serial5 to Serial4 to Serial3 to Serial2 to USB.

Attached sketch doing this at 3Mbaud - it fails at 4MBaud somewhere in the chain.
UPDATE: Updated version including Serial6, at 240 MHz it seems to do 17Kcps at 4Mbaud.

 

[duff]

USB1 will route to a location to solder a 5 pin header, as described in msg #93 with the pinouts.

So it looks like you can wake up from LLS and VLLS(x) in USB host mode with this chip (MK66) then by configuring the D pins as a pin interrupt.

I have Snooze v5 working mostly now but haven't measured the current consumption yet in sleep modes. This chip is actually like the TeensyLC when it comes to low power (LLS, VLLS(x)) for the wakeup modules (TSI, CMP) which means you have to use the LPTimer as a clock source to those modules so you can't use the LPTimer along with them. Maybe I can use another clock but not sure yet.

Next I'm going to investigate using the IRC48M clock at 16 MHz and below which it seems like it will work according to the ref manual. Actually I need to see if those low cpu speeds even work yet. This clock can also be active in Wait and Stop modes but not LLS or VLLS(x) modes.

An as a side note I tested the Audio library's NoteFrequency example all the way up to 240 MHz and it worked!

 

[KurtE]

I extended my function test with serial 'Loop Through' - works up to 3,000,000 baud. With wiring serial PORT to PORT :: pins>1-34,33-31,32-7,8-9
...

Sounds like this is pretty well done for this round.

On the transmitterEnable pin code, was wondering if anyone has tried the hardware support for this on the RTS pin.
Something like:

void serial_set_transmit_pin(uint8_t pin)
{
...
	if (pin == 6) {
		CORE_PIN6_CONFIG = PORT_PCR_MUX(3);
	} else if (pin == 19) {
		CORE_PIN19_CONFIG = PORT_PCR_MUX(3);
        }
...
	UART0_MODEM |= UART_MODEM_TXRTSE | UART_MODEM_TXRTSPOL;
}

I will probably punt for now, thought this might be new stuff as it mentions hardware support for RS-485, but it looks like these same flags may be valid for T3.2... So I might take a look later, probably different thread.

Edit: I think it will Work, I edited my AX12Test Sketch, set for Serial1, with direction pin 2... Then after the init, I did:

  // Hack to see if I can make pin 6 act like SERVO_DIRECTION_PIN
  CORE_PIN6_CONFIG = PORT_PCR_MUX(3);
  UART0_MODEM |= UART_MODEM_TXRTSE | UART_MODEM_TXRTSPOL;

Did a test run, which assume screen shot is OK:

The third line is the software controlled direction line and the last pin shown is for pin 6, which is controlled by the UART

 

[defragster]

Sounds like this is pretty well done for this round.

Looks good to me. Data transfers in and out of each port under 'system' control (serialEvent) - even when pushed to higher speeds and doing large data blocks 80 and 161 per transmission every 6 ms? I didn't read if they all have fifo's what what the buffer size is - but it works. Seems to do higher throughput at 2Mb than 3.2 (as in the other thread?)

Rewrote to use readBytes() in the 4 active serialEvent()'s and 120 MHz can do 13.7K cps before losing data at 3.2Mb - double that at 2 Mb and 240 can do 27K cps (2 or 3.2 Mbaud) hopping through the loop s5><s4><s3><s2>USB at 3.2Mbaud before signs of data loss.

I was running 216 MHz - went up to 240 and down to 180 & 120 MHz and they could all start and maintain that for 3.2Mb. Compiled at 96MHz and that failed to start with 3.2MBaud , just like 4Mbaud at 240 - though it runs fine at 96 MHz when only pushing 2Mb/s and does 17K cps.

All it takes is 4 jumper wires - and this version blinks!
View attachment Only_qBlink_LoopB.ino

.

 

[duff]

Next I'm going to investigate using the IRC48M clock at 16 MHz and below which it seems like it will work according to the ref manual. Actually I need to see if those low cpu speeds even work yet. This clock can also be active in Wait and Stop modes but not LLS or VLLS(x) modes.

Haha 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. Now I wonder what the power usage is using this clock? It might be kind of fruitless because I think the way I have had to use configure it would mean the IRC48M clock is being used for peripherals also, I don't know yet just wanted to see if would work first.

 

[defragster]

EEPROM write testing: My thought was to test the various EEPROM Functions: read(),write(),update(),get(),put(),EEPROM[] - and of course test the access across boundaries, I skipped update() since the code reads and tests before writes as I saw it in all cases.

Allowing for the need of the pending drop out of HSRUN for EEPROM access - I tested at 96 MHz. Good news NO READ WRITE ERRORS in testing.

Starting with the Manitou sketch meant to confirm timing - I ended up with a master loop of 25 passes writing 164 bytes - so the last bytes four give access errors.

The first 50 bytes are char arrays of 16,8,4,2,9,7,3,1 written in that order using put(), the next 50 bytes the 1 byte is written first, then the rest skipping the last one byte - so if it wasn't odd the first time - it is the second. [Of course as soon as I write that 163 is prime what a great multiplier.] Then a simple write of 32 bytes EEPROM[] array style, then 32 byte written with a one byte write.

So every byte gets a repeatable value - the offset into the block of 164 bytes PLUS a fixed test value for that run.

Two observations: Some blocks take much longer to write with a new value 1,470,077 .vs. 52,954 micros.

Second: In some cases the second write times indicate that the unchanged value caused 'no write' with 171 micros, others are slower at 3116 us, some actually take really long at 1,051,167 us. The number of some it seems is HALF - yep every other one - if anyone has a clue let me know as I hope to look at the code a bit.

Will post a sketch soon - I just have to try the 163 byte blocks. I also need to format the output as CSV so it can be table ordered and the boundaries better seen.

<EDIT>: I got my test refined - the write times are uniform - the problems were in my code. Will post when high HSRUN EEPROM access is released.

 

[Pedvide]

Opps, sorry about that. There were only a couple version 5 boards. They just got mixed in, without any way of tracking who got which version... and of course we ended up with bad luck that a version 5 went to the one person who really needs access to all the analog pins!

If you'd like, we can swap it for a version 6 board next week.

I believe we're down to just nine round 2 boards left, with 7 of them not yet soldered. I just checked and all 9 of them are version 6. If we're going to swap it so you can access those 3 pins, now's the time!

Murphy's law always applies! haha
I think it's ok, I can test the differential code on A12-A13, and when everything is ready I'll update the library and ask somebody with a PROTO6 to test A10-A11. I'll probably buy a board when they are ready.

 

[manitou]

Found a small issue: number of sectors is always an odd number (setting 4 or 5 will read 5 sectors)
If this is a K66 bug or bad programming, I do not know yet.

I confirmed with my microSD card, i get the "extra" sector on even multi-block reads. To investigate, instead of DMA, I configured for SWPOLL. It will read 1 sector, but hangs if I try multi-sector read. Have you played with SWPOLL at all? Since DMA works, may not be worth pursuing ...

EDIT: with COUNT of 4, I looked at SDHC_BLKATTR register after read: 0x50200
Masks and shift look OK (i think) in your .h, but changing CMD18 to use
SDHC_BLKATTR = SDHC_BLKATTR_BLKCNT(count) | 512;

gives me 4 sectors, when i ask for 4 sectors. (the BLKCNT field is a little weird on reset/read, it get sets to 1, but i still don't see why masks and such aren't working

 

[WMXZ]

I confirmed with my microSD card, i get the "extra" sector on even multi-block reads. To investigate, instead of DMA, I configured for SWPOLL. It will read 1 sector, but hangs if I try multi-sector read. Have you played with SWPOLL at all? Since DMA works, may not be worth pursuing ...

No I have not tried SWPOLL, as my application asks for DMA.

 

[WMXZ]

uSDFS

I ported ELM-CHaN's FATFS to K66 as Teensy library

https://github.com/WMXZ-EU/uSDFS

original is from http://elm-chan.org/fsw/ff/00index_e.html

 

[WMXZ]

I confirmed with my microSD card, i get the "extra" sector on even multi-block reads. To investigate, instead of DMA, I configured for SWPOLL. It will read 1 sector, but hangs if I try multi-sector read. Have you played with SWPOLL at all? Since DMA works, may not be worth pursuing ...

EDIT: with COUNT of 4, I looked at SDHC_BLKATTR register after read: 0x50200
Masks and shift look OK (i think) in your .h, but changing CMD18 to use
SDHC_BLKATTR = SDHC_BLKATTR_BLKCNT(count) | 512;

gives me 4 sectors, when i ask for 4 sectors. (the BLKCNT field is a little weird on reset/read, it get sets to 1, but i still don't see why masks and such aren't working

I was thinking along the same line (that is why I printed SDHC_BLKATTR after read)
Will continue with your single assignment version

Edit: sdhc-test and uSDFS are corrected to use multi-sector operations correctly

EDIT: removed shdc_test from GitHub as functionality is in uSDFS

 

[manitou]

Edit: sdhc-test and uSDFS are corrected to use multi-sector operations correctly

You might remove your CAVEAT from Readme in uSDFS github?

? if i do
SDHC_BLKATTR &= ~(SDHC_BLKATTR_BLKCNT_MASK);
SDHC_BLKATTR |= SDHC_BLKATTR_BLKCNT(4);
in a sketch, they work as expected. I don't know they arent working in sdhc.c ??? weird, weird, weird

 

[Pedvide]

I've updated the ADC library to support Teensy 3.4/3.5.
I've tested it on the Teensy 3.5 PROTO5 I have, however I have no access to the A10-A11 pins, could some of you with the PROTO6 board test those for me?
Download the latest version from github and run the example readAllPins.ino. Check if the pins A10 (column #10), A11 (column #10) and the differential results are correct.

 

[manitou]

I ported ELM-CHaN's FATFS to K66 as Teensy library

https://github.com/WMXZ-EU/uSDFS

original is from http://elm-chan.org/fsw/ff/00index_e.html

I ran the example (you need Serial.printf for printf in die()), commented out write/read, and got directory listing OK. then tried to read my RAW.DAT, but sketch hung on

rc=f_read(&fil,(void *)sector,sizeof(sector),&lth);

Maybe file structure that wrote RAW.DAT different from uSDFS?? further study required...

EDIT: I can read TST.C with f_gets() -- is my semantics for f_read() wrong ??

 

[manitou]

I've updated the ADC library to support Teensy 3.4/3.5.
I've tested it on the Teensy 3.5 PROTO5 I have, however I have no access to the A10-A11 pins, could some of you with the PROTO6 board test those for me?
Download the latest version from github and run the example readAllPins.ino. Check if the pins A10 (column #10), A11 (column #10) and the differential results are correct.

am I supposed to jumper any pins?? here is snippet of output

0: 2.20. 1: 2.10. 2: 1.94. 3: 1.72. 4: 1.80. 5: 1.68. 6: 2.23. 7: 1.99. 8: 2.10. 9: 2.26. 10: 2.45. 11: 1.71. 12: 1.95. 13: 1.63. 14: 1.98. 15: 1.86. 16: 2.46. 17: 2.21. 18: 2.14. 19: 2.11. 20: 2.39. 21: 2.33. 22: 1.80. 
Differential pairs: 0: 0.85. 

0: 2.20. 1: 2.11. 2: 1.97. 3: 1.68. 4: 1.68. 5: 1.60. 6: 2.17. 7: 1.89. 8: 2.11. 9: 2.30. 10: 2.54. 11: 1.86. 12: 1.98. 13: 1.68. 14: 1.89. 15: 2.01. 16: 2.51. 17: 2.33. 18: 2.29. 19: 2.34. 20: 2.38. 21: 2.39. 22: 1.79. 
Differential pairs: 0: 0.88. 




if i jumper A10 to A11

0: 1.98. 1: 1.98. 2: 1.80. 3: 1.76. 4: 1.59. 5: 1.64. 6: 2.16. 7: 1.92. 8: 2.07. 9: 2.21. 10: 2.33. 11: 1.85. 12: 1.98. 13: 1.64. 14: 1.95. 15: 1.92. 16: 2.51. 17: 2.29. 18: 2.26. 19: 2.30. 20: 2.41. 21: 2.34. 22: 1.80. 
Differential pairs: 0: 0.01. 

0: 1.97. 1: 1.97. 2: 1.77. 3: 1.62. 4: 1.68. 5: 1.71. 6: 2.24. 7: 2.07. 8: 2.06. 9: 2.23. 10: 2.34. 11: 1.73. 12: 1.98. 13: 1.66. 14: 2.04. 15: 2.02. 16: 2.51. 17: 2.34. 18: 2.16. 19: 2.19. 20: 2.33. 21: 2.34. 22: 1.84. 
Differential pairs: 0: 0.01.

 

[Pedvide]

manitou,

Set pin A10 to 3.3V and A11 to GND. Check the value of
Differential pairs: 0: x.xx
it should be 3.3. Then switch A10 to GND and A11 to 3.3V and see if it becomes -3.3.
The values of A10 and A11 are given in the row above, make sure they are 0V or 3.3V
0: 1.97. 1: 1.97. 2: 1.77. 3: 1.62. 4: 1.68. 5: 1.71. 6: 2.24. 7: 2.07. 8: 2.06. 9: 2.23. 10: 2.34. 11: 1.73. 12: 1.98.....

 

[manitou]

manitou,

Set pin A10 to 3.3V and A11 to GND. Check the value of
Differential pairs: 0: x.xx
it should be 3.3. Then switch A10 to GND and A11 to 3.3V and see if it becomes -3.3.
The values of A10 and A11 are given in the row above, make sure they are 0V or 3.3V
0: 1.97. 1: 1.97. 2: 1.77. 3: 1.62. 4: 1.68. 5: 1.71. 6: 2.24. 7: 2.07. 8: 2.06. 9: 2.23. 10: 2.34. 11: 1.73. 12: 1.98.....

OK,

with GND to A10,   3.3v to A11
0: 1.66. 1: 1.97. 2: 1.79. 3: 1.77. 4: 1.64. 5: 1.62. 6: 2.25. 7: 2.03. 8: 1.92. 9: 2.11. 10: 0.01. 11: 0.56. 12: 2.02. 13: 1.68. 14: 1.53. 15: 1.90. 16: 2.42. 17: 2.21. 18: 2.19. 19: 2.12. 20: 2.37. 21: 2.38. 22: 1.75. 
Differential pairs: 0: -3.30. 

0: 1.67. 1: 1.97. 2: 1.81. 3: 1.82. 4: 1.79. 5: 1.62. 6: 2.25. 7: 2.03. 8: 1.93. 9: 2.16. 10: 0.01. 11: 0.56. 12: 1.97. 13: 1.60. 14: 1.53. 15: 1.72. 16: 2.39. 17: 2.20. 18: 2.16. 19: 2.12. 20: 2.32. 21: 2.33. 22: 1.79. 
Differential pairs: 0: -3.30. 



with A11 to GND, A10 to 3.3v
0: 2.60. 1: 2.16. 2: 1.84. 3: 1.73. 4: 1.84. 5: 1.67. 6: 2.10. 7: 1.95. 8: 1.98. 9: 2.15. 10: 3.30. 11: 2.69. 12: 2.04. 13: 1.76. 14: 2.12. 15: 2.12. 16: 2.43. 17: 2.25. 18: 2.20. 19: 2.25. 20: 2.42. 21: 2.51. 22: 1.92. 
Differential pairs: 0: 3.30. 

0: 2.60. 1: 2.16. 2: 1.84. 3: 1.70. 4: 1.85. 5: 1.70. 6: 2.20. 7: 1.92. 8: 2.06. 9: 2.23. 10: 3.30. 11: 2.69. 12: 2.04. 13: 1.79. 14: 2.14. 15: 1.97. 16: 2.46. 17: 2.25. 18: 2.19. 19: 2.23. 20: 2.41. 21: 2.38. 22: 1.88. 
Differential pairs: 0: 3.30.

differential looks good, but running values ??

 

[Pedvide]

Well the differential value is correct, and so is A10, but A11 isn't right so i'll fix it and let you now so you can test it again.
Thank a lot manitou!