Teensy 4.0 First Beta Test

Status
Not open for further replies.
Which version & rev of Windows is this? Very strange that it's not loading a driver for a HID interface.

Looking at post #2295 image it shows the same text @mjs513 reported - that was after the 15s Restore.

This is latest Win 10 1809.17763.437. It popped up an install window but I missed clicking it.

Did another 15s Restore and moved to another USB port and Win 10 reported this on install:
Win10_SEBlank.jpg

Paul - would it help if you posted the HEX stored in Flash to do a manual install and see if it acts the same?

It puzzles the IDE and TeensyPorts too?
Previously selected Teensy port is offline.
3 other Teensy boards found. Please select
a Teensy from the Tools > Ports menu.

Looking at IDE with Powered T4-2 connected it is missing: 15sRestoreAgain.jpg

Ref - here is TeensyDuino Log:
View attachment Win10Restore_Blank.txt

Worked with button press and now Ports is like this:
15sRestoreAgainButton.jpg
 
Last edited:
Looks like I have to wait until tomorrow as, our mailbox place did not sort through packages until afternoon... :(
 
Looks like I have to wait until tomorrow as, our mailbox place did not sort through packages until afternoon... :(

Bummer KurtE :( You'll be impressed when you see it.

Power Button working well so far - not sure how to abuse it ... Held it during plug in and Button press and while in bootloader in a few combinations I could think of - all acted reasonably. It doesn't take running code to activate. Worked when MCU is FAULTED flashing or in bootloader

I did get the IDE and TeensyLoader Horribly confused {as it does} - it tried putting the T4-2 code into a T_3.1 and brought up the dialog to tell me and then it is forever dedicated to being wrong - even getting the T4-2 back online and button press it stays fixated on the T_3.1
 
Using TLoader to upload that minimal.HEX file works normally it seems:
T4-2RestoreHex.jpg
And Ref log:View attachment RestoreHex.txt

versus :: "[no_device] …" after 15s Restore

NOTE: I did 15s Restore and got no_device … TLoader uploaded the minimal.hex and the TPorts entry did not update until I repowered the T4-2. Repowering the T4-2 after 15s Restore did NOT take away the no_device.

Trying to get back to the open BLINK.ino I get { this is after 15Restore } - no prob afte manual minimal.hex upload:
Error opening HID device
Windows Error Info: The system cannot find the file specified.
Teensy did not respond to a USB-based request to enter program mode.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.
 
Last edited:
Since putting the beta1 board on hold for awhile I've started looking at the low power features again and was wondering if the new beta2 boards will have the bootloader go into lower power mode. Sorry if missed any info on this front but last I heard that the bootloader does not go into low power mode.

For some of the low power modes you have to turn off the PLL's manually so what PLL's are activated from reset? I see the ARM and USB1 PLL's are in startup.c and clock speed.c any others?

I've got it to wake from System Idle Mode using the PIT so far.
 
@KurtE - @defragster is right - you are missing all the fun. But tomorrow is another day.

Anyway while @defragster is working on the port issue I went ahead and tried the Bluetooth version of USBHost_t36 using the USBHost_viewer sketch which also uses the ILI9488_t3 lib.

As most of my hardware is put away (will get tomorrow) I tested it with the PS4 controller in wired mode and Bluetooth mode and basically it works just the same way as on the T4B1 and T3.6. Will test some other devices tomorrow but don't think they will be a problem.
 
The remaining 5 beta #2 boards shipped today, to WMXZ, Manitou, Tonton81, MXXX, and Duff.

I have 2 more boards that experienced problems while testing. I'm going to look into what went wrong on those, and if it's something I can be sure is fixed, we might get 2 more to send soon.

Today I ordered PCBs for a small pre-production run. We still don't know the exact time frame, but it's likely about 2 weeks until we have more boards. These pre-production boards have the bottom-side pads for native SD changed to a 1 mm pitch for a FFC connector. They also have a fix for the PMIC_ON_REQ pullup resistor. If have have one of the beta2 boards, just above pin 2 you'll see a resistor standing on its side and soldered diagonally between pads. That's fixed on the latest PCB rev. Other than that resistor and the pads for native SD, everything will be pretty much the same as beta2.
 
On Windows 10 - first upload after 15sRestore requires Button press - it can't upload with the no_device HID. That explains the "Error opening HID device" post 2306.

I just tried TyCommander and it doesn't 'know' the NEW USB ID of the T4-2. I forwarded some info to @koromix that should let him present an update. It works for SerMon - but fails on Upload.

Paul - Thanks for the Green Power LED - at least once after OFF testing I wondered where the T4-2 was :)

Saw something odd - held RestoreButton too long? Once - haven't figured out what I did - Red BootLight stayed on?

@KurtE - I'll wait until you have a chance to test your github CORES before using it.

@FrankB - First time I got a Beta delivery before you did! Hopefully yours isn't hung up in Customs. In the box was one single assembled 'T4-2 USB Development Board Prototype' with Price of $0.00.
[ breakout board with mounted T4-2 and Audio Shield ]
 
Last edited:
The remaining 5 beta #2 boards shipped today, to WMXZ, Manitou, Tonton81, MXXX, and Duff.

I have 2 more boards that experienced problems while testing. I'm going to look into what went wrong on those, and if it's something I can be sure is fixed, we might get 2 more to send soon.

Today I ordered PCBs for a small pre-production run. We still don't know the exact time frame, but it's likely about 2 weeks until we have more boards. These pre-production boards have the bottom-side pads for native SD changed to a 1 mm pitch for a FFC connector. They also have a fix for the PMIC_ON_REQ pullup resistor. If have have one of the beta2 boards, just above pin 2 you'll see a resistor standing on its side and soldered diagonally between pads. That's fixed on the latest PCB rev. Other than that resistor and the pads for native SD, everything will be pretty much the same as beta2.

Great news on those other 5 boards going out! Good luck with diagnosing/resurrecting the two 'problem' units.

I saw that odd diagonal on edge resistor - didn't figure that was planned for production :)

@mjs513 - Good work on USB testing. I was going to go there - but got distracted by pushing buttons. I'll do a quick test knowing it should work if my hardware is good. It looks like I have some 90 sketches in my T4 folder - I'll go back to a few of the base ones for some simple usage tests.
 
TD 1.46 released:
Win 10 downloaded TD_1.46 for IDE 1.8.9.

Installed and ran properly to upload Blink to T_3.5 and see millis() on SerMon!

What I didn't post there is that ...\hardware\teensy\avr\boards.txt needs edit to enable Beta T4's.

Global Replace of : '#teensy4b' with 'teensy4b' to enable both boards b1 and b2.

Then same blink uploaded well to the Beta T4's
 
Running some initial sketches - showing the things I hit/fixed or dealt with early T4-1

Using IDE 1.8.9 on Win 10 w/TD_1.46.

This is a fail I didn't look into ...
-- > My copy of COREMARK is starting but never finishing? It was faulting IIRC when '#define ITERATIONS 10000' was too big - like 25K - I set it to 10K and it is stuck - also did not fault at 48K - but failed to end? I didn't plug in Debug Serial yet.

== > When no Serial SerMon connect any output stalls the processor - known issue until Core USB gets update

These are all good:
++ > Startup time - entry to setup() and first Serial. Online to IDE SerMon is good:
T:\tCode\T4\BlinkMin\BlinkMin.ino Apr 22 2019 21:55:42
Setup First millis=305
Serial First millis=484

++ > Digital Read and Write Fast or not_Fast cycles the LED pin

++ > Check on Micros is working for single 1 us resolution from micros()

++ > ARM_DWT_CYCCNT is active on entry to Setup()

++ > Quick note the RTC seems to be running when powered between restart. Not actually looking at value in this test

++ > Quick note the RTC set seems to SURVIVE POWER OFF and ON - maybe just CAP charge? - again not watching for change in clock. Sat 20 min OFF on USB and RTC not reset.
 
Last edited:
@FrankB - Hope your drive Goes/Went well - and that your T4-2 arrived in good shape and without hassle.

Found another RTC sketch - it also was changing with set_arm_clock(600000000);

> RTC keeps time with my PC while running across speeds 800 MHZ to 100 MHz and many uploads some past hour.

> RTC does indeed Run and keep updating time while 'OFF' - this is on USB power with no VBat power.

> Simple loop runs fine at those changing speed - doing delay(1000) and then changing speed each 30 secs.

> Using tempmonGetTemp(); is working and tracking the CPU speed - modified sketch for quick and dirty tracking after 30 secs
Code:
	99428571 MHz °C=39.000000 < At startup from 'OFF' with finger cooling after OFF
	99428571 MHz °C=45.086956
	201000000 MHz °C=45.695652
	300000000 MHz °C=46.304348
	402000000 MHz °C=47.521740
	498000000 MHz °C=48.130436
	600000000 MHz °C=51.173912
	696000000 MHz °C=54.217392
	804000000 MHz °C=56.652172

Heat Sink metal fin side down laying on MCU:
Code:
	99428571 MHz °C=37.782608
	201000000 MHz °C=38.391304
	300000000 MHz °C=40.217392
	402000000 MHz °C=41.434784
	498000000 MHz °C=42.652172
	600000000 MHz °C=45.695652
	696000000 MHz °C=46.913044
	804000000 MHz °C=49.347828
 
Last edited:
I did test the button on all 9 boards. It worked at least once, ~5 sec to turn off power, about half a second to turn it back on.
But the pogo pin for that button, and the tiny pins for the SD card aren't ideal.
...

As noted my Breakout On/Off working - I tried compressing and releasing the pin to get a better connect and that failed - no voltage from the PCB pad on the POGO barrel. But the least bit of compression with a smaller contact area on the tip of pin to tip of the DVM Probe made a connection. Almost like the pin was floating and internally disconnected. As working with the small metal leg in there it is causing compression - but not likely any more contact area.

I noticed the 3.3V pin goes to 0 volts in Power Off state.

800 MHz stable - not doing anything but loop() watching for second passage. What is a good busy loop to run while waiting for a second to pass? BhuddaBrot calc?

Re-ordered the code watching temps as speed changes upwards I started it cooled and OFF - RTC secs still tracking PC Clock across 'Power Off'. It started low but now heat soaking is pushing up temps seen as it loops and not cooling in 25+ secs from 800 MHz to 100 MHz drop.
Code:
	99428571 MHz °C=37.173912 << In setup() w/speed drop ASAP
	99428571 MHz °C=49.956520
	201000000 MHz °C=49.347828
	300000000 MHz °C=49.956520
	402000000 MHz °C=50.565216
	498000000 MHz °C=51.173912
	600000000 MHz °C=54.217392
	696000000 MHz °C=56.652172
	804000000 MHz °C=59.086956
	804000000 MHz °C=59.086956 << Max temp seen

Many compiles and uploads and nothing seems wrong with T4-2 operation in that regard or the few parts I've hit. Nice Work!
 
@defragster
Wow - you made a lot of progress over night. Don't you ever sleep ;)

I'll check out coremark today, think we need to update the list of things like in post 4; or just annotate B2 next to what works before we loose track.
 
@defragster

Just checked coremark at 10000 and 30000 iterations and both ran without issue - didn't see the hanging. The interesting thing is it reported errors at 10K (not enough time to run but ran) but not 30K:
Code:
2K performance run parameters for coremark.
2305304 us 4356854 
CoreMark Size    : 666
Total ticks      : 4356829
Total time (secs): 4.356829
Iterations/Sec   : 2295.247300
[COLOR="#FF0000"]ERROR! Must execute for at least 10 secs for a valid result![/COLOR]
[COLOR="#FF0000"]Iterations       : 10000[/COLOR]
Compiler version : 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
Compiler flags   : 
Memory location  : STACK
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x988c
[COLOR="#FF0000"]Errors detected[/COLOR]
.... done
done

At 30K
Code:
2K performance run parameters for coremark.
2305304 us 13070502 
CoreMark Size    : 666
Total ticks      : 13070478
Total time (secs): 13.070478
Iterations/Sec   : 2295.248881
Iterations       : 30000
Compiler version : 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
Compiler flags   : 
Memory location  : STACK
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x5275
Correct operation validated. See readme.txt for run and reporting rules.
CoreMark 1.0 : 2295.248881 / 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]  / STACK
.... done
done

For comparison
Code:
[COLOR="#FF0000"]   T4 (fastest)@ 600    2427.4  
vs T4B2 (Faster)@600     2295.2 
   T4B2(Fastest)@600     2426.9[/COLOR]
 
@defragster
Wow - you made a lot of progress over night. Don't you ever sleep ;)

I'll check out coremark today, think we need to update the list of things like in post 4; or just annotate B2 next to what works before we loose track.

Forgetting to sleep tonight it seems - did well last night :) - I'll get to that ASAP.

My thought was to keep a quick 'Smoke Test' log in the indicated 'Teensy 4.0 SECOND Beta Test with 1062 post #2280' given the low number of 1062's out there - and many initial things will get fixed that don't relate to the first page posts. Editing first page post tables is a bit of effort in itself. I think I noted - certainly any updates or adds need to get on the first page posts - but first pass things like I've collected in #2280 for tracking would keep them from getting lost/duplicated effort - like changing RAM space, initial audio edits, added pins - but nothing in that post can get lost if it collects there - versus the barrage that will follow.

For T_3.6/3.5 I kept such a workspace for links. Paul mostly allowed for that on Page 1 posts … for First Beta ...


I must have corrupted my copy of CoreMark - it had a fault before I was trying to locate. Maybe post your copy?
 
Editing first page post tables is a bit of effort in itself. I think I noted - certainly any updates or adds need to get on the first page posts - but first pass things like I've collected in #2280 for tracking would keep them from getting lost/duplicated effort - like changing RAM space, initial audio edits, added pins - but nothing in that post can get lost if it collects there - versus the barrage that will follow.

For T_3.6/3.5 I kept such a workspace for links. Paul mostly allowed for that on Page 1 posts … for First Beta ...

Please do edit the messages 2-6 as needed. They do apply to 1062, regardless of the name of the thread.
 
ENCODER LIBRARY and H/W ENCODER/XBAR

Did a short test using the standard encoder library on pin sets(0,1), (7,8) and no issues. Did the same test using the H/W Encoder Sketch and showing same results as the 1052. So would say verified on 1062 as well
 
SD CARD on Board

@KurtE

Using your spreadsheet I tried to read the sd card on the breakout board:
Code:
const int chipSelect = 36;

void setup()
{
  //UNCOMMENT THESE TWO LINES FOR TEENSY AUDIO BOARD:
  SPI.setMOSI(35);  // Audio shield has MOSI on pin 7
  SPI.setSCK(37);  // Audio shield has SCK on pin 14  
  SPI.setMISO(34);
...…..

And managed to get my first hardfault with the B2. Told you if anyone would do that it would be me :)
Code:
 _CFSR ::  00000082
      (DACCVIOL) Data Access Violation
      (MMARVALID) MemMange Fault Address Valid
 _HFSR ::  40000000
      (FORCED) Forced Hard Fault
 _DFSR ::  00000000
 _AFSR ::  00000000
 _BFAR ::  2C524F56
 _MMAR ::  2C524F56
I have to double check but I did use your updated core files. So question is how do you read the SD Card on the breakout board?
 
Status
Not open for further replies.
Back
Top