Teensy 4.0 First Beta Test

Status
Not open for further replies.
I've been working on the bootloader, which is why I've been kinda quiet these last couple days.

I believe I've finally found the bug that been causing a corrupted image to be written after the 15 second restore. The restore process was also failing to wipe the EEPROM memory.

Also fixed a bug where the red LED doesn't turn off if you press (and hold) the pushbutton while T4 was already in bootloader mode. It was working properly, but the red LED behavior made it really confusing, especially if you try to do the 15 second restore while already in bootloader mode.

I'm also expanding the flash usable for program space from 1536K to 1984K. 60K is reserved for EEPROM emulation, and the last 4K holds a read-only copy of the restore program.

Going to package up 1.47-beta3 soon, which will update the 1062 boards with the brown-out restart fix to bootloader version 0.04. The earlier 1062 boards which have the brown-out issue will not upgrade. They're permanently fixed at bootloader version 0.03. If anyone actively testing has only that board stuck on 0.03, email me and we'll get you a new board.
 
Nice, looking forward to 1.47-b3. Cool spec - 1.9375 MB of code space.

I never knew what to expect from the RED led so was just happy it was there … good you are seeing it right.

noted … 15s Restore will wipe EEPROM. :: Seems a reasonable measure - knowing all is then fresh and clean. Suppose the T_3.6 doesn't do that as it isn't a creation subject to confusion.

The Pre-Mod T4B2's will still work the same as the T4B2M's - with the code space growth and EEPROM function? Just not get altered bootloader updates to RED LED and 15s Restore fixes.

No change in device ID or other affecting TyComm uploads - after at least one to get the new bootloader?
 
I'd really like to stay focused on the current 1062 boards, with the brown-out restart fix. I want you to put those older boards on a shelf. You can keep them for a project, but there's no point doing anything more with the older hardware in the context of beta testing and this lengthy thread. Beta test only with the latest hardware I've sent you. Please, let's stop talking about those old boards on this thread. Leave them in the past.

To quickly answer your question, which I hope will be the last talk of these old boards, the non-upgradable 1062 boards and the first 1052 boards may or may not work. I'm not testing them. 1.47-beta3 will let you create a program larger than 1536K, which won't work on the old boards, but you should get an error message explaining the size limit. As far as I know, everything else should still work. But I'm not testing and if any problem does come up affecting only those old boards, it will not be fixed.

At some point in the future, probably without any notice or warning, changes are likely to be incompatible with those earliest boards. Archive a copy of the Teensyduino beta installer which supports those old boards... so you can someday use those old boards in a project. Please, from this moment forward, discontinue all use of the first 1062 board (with brown out issues) and the 1052 board for beta testing. Test only with the latest 1062 boards which have the brown-out restart fix.

For anyone (on the beta testers list in msg #1) with only the old 1052 or early 1062 boards, email me and we'll get you the latest hardware.
 
I'd really like to stay focused on the current 1062 boards, with the brown-out restart fix. I want you to put those older boards on a shelf. You can keep them for a project, but there's no point doing anything more with the older hardware in the context of beta testing and this lengthy thread. Beta test only with the latest hardware I've sent you. Please, let's stop talking about those old boards on this thread. Leave them in the past.

> That is exactly the answer I've been asking for.

The only thing I had in mind - with it sitting on a shelf … was perhaps an EEPROM test to the death with random manipulations verifying the stored/recalled values logging to USB HDD in the event it shows some failure - wanting to know if that would even relate to the final product where the EEPROM code should be the same and the pre_Mod B2 board only change is the white wire that won't be a factor under constant power and no reprogramming.

...For anyone (on the beta testers list in msg #1) with only the old 1052 or early 1062 boards, email me and we'll get you the latest hardware.
 
I've uploaded 1.47-beta3. Links on msg #2.

This version will upgrade your T4's bootloader to 0.04, which (hopefully) fixes the 15 sec restore process, and several other minor bootloader issues.

Teensy Loader and the new bootloader also now automatically initialize the RTC to your PC's time.

Again, if anyone (on the beta testers list in msg #1) has only the first 1062 board which won't upgrade, or only the early 1052 board, please email me directly and we'll send you the latest hardware.
 
@PaulStoffregen

Know this question is off topic for T4 development but you mentioned the T4 release will be in mid-July sometime. Does that mean you will start a kickstarter or equivalent around that time as well?
 
Just installed 1.47-Beta3 and on 15 sec hold the bootloader updated (looked at verbose messages). This was done with the T4B2R (for ribbon board).

1. Did a 15 sec restore red light blinked once and then came on steady until restore process was complete and it started blinking.

2. Second test was doing a 15 sec restore as in one but this time with the red light steady I did another restore. After another 15 sec (with the first restore hitting) the red light blinked came on steady and then did the restore.

EDIT: Repeated the steps with the T4B2 board with white wire on the bottom with the same results. Did notice that the restore process does take a while.
 
Re: T4 EEPROM
FWIW, i did a few more EEPROM tests on both 1052 and 1062. I confirmed that if flash sector is filled, core properly preserves current data bytes and reflashes sector and restores current data bytes.

I have a T4 EEPROM meta-data sketch that i use to dump flash sectors and and sector index table.

the eeprom sector index table on my T4B2
Code:
EEPROM lth 1080 flash 16 sectors 65536 bytes  0x601f0000 to 0x601fffff
sector 0  index 308  last 0:53
sector 1  index 156  last 127:42
sector 2  index 148  last 71:0
sector 3  index 149  last 75:0
sector 4  index 148  last 79:0
sector 5  index 148  last 83:0
sector 6  index 148  last 87:203
sector 7  index 149  last 1050:18
sector 8  index 148  last 95:199
sector 9  index 148  last 99:125
sector 10  index 75  last 103:132
sector 11  index 75  last 107:27
sector 12  index 75  last 111:89
sector 13  index 75  last 115:33
sector 14  index 75  last 119:134
 
Last edited:
Re: T4 EEPROM
FWIW, i did a few more EEPROM tests on both 1052 and 1062. I confirmed that if flash sector is filled, core properly preserves current data bytes and reflashes sector and restores current data bytes.

I have a T4 EEPROM meta-data sketch that i use to dump flash sectors and and sector index table.

Cool - just saved a copy for future use :) Did you ever retest Prop Shield?
 
Did you ever retest Prop Shield?

Yes, my disjointed CalibrateSensors and MotionCal (on another machine) worked after Paul's eeprom.c fix.

I just installed 1.47-beta3 on T4B2 and it said bootloader updated. I actually thought i had an older T4B2 that wouldn't update bootloader??
How do you read the version of bootloader (i tried turning on verbose in teensyloader, but didn't see a version number?)

various EEPROM tests (including power cycle tests) worked with 1.47-beta3 on my T4B2

Re: EEPROM erase when holding button for 15 s.
One could argue against erasing EEPROM via the button, but rather add a method to do EEPROM.erase()
 
… Re: EEPROM erase when holding button for 15 s.
One could argue against erasing EEPROM via the button, but rather add a method to do EEPROM.erase()

I was going to suggest/argue that as well … but left it at 'reasonable' …

Will get to new Beta in a few hours … sounds promising.
 
I've uploaded 1.47-beta3.
Teensy Loader and the new bootloader also now automatically initialize the RTC to your PC's time.

Yep, RTC is set to correct time and is ticking ;)
Code:
// T4 RTC  32khz crystal 
#include <time.h>

void setup() {
}

void loop() {
  time_t tt = rtc_get();
  Serial.printf("%s", ctime(&tt));
  delay(1000);
}
 
manitou said:
I just installed 1.47-beta3 on T4B2 and it said bootloader updated. I actually thought i had an older T4B2 that wouldn't update bootloader??
How do you read the version of bootloader (i tried turning on verbose in teensyloader, but didn't see a version number?)
Saw it updating in bootloader as well but I didn't see the version number either. Pretty much have the same question as you - how do you get the version number of the bootloader?
 
I've uploaded 1.47-beta3. Links on msg #2.
With beta3, i had to re-apply hack to audio lib play_sd_wav.h and .cpp to fix BUILTIN_SDCARD WavFilePlayer bug in T4, T3.6, T3.5, see
https://forum.pjrc.com/threads/5635...ignment-issues?p=206982&viewfull=1#post206982

EDIT: well, that allowed T3.6 WavFilePlayer to run, but T4B2 hangs. ??

EDIT 2: reseating audio shield and using different USB port (?) on linux box, and now WavFilePlayer working on T4B2 with beta3 and hacks to audio lib
 
Last edited:
Assuming there will be no kickstarter for the T4, the question to PJRC (I mean Robin) is if you accept pre-release orders (don't care about final price)?
 
Wonder if this is a related problem to what I seeing in trying to run the datalogger example on the T4 with the builtin_sdcard, see post 3135. Seen in both 1.47-beta2 and bet3

Well, BUILTIN_SDCARD WavFilePlayer (with audio lib hacks) is working now on my T4B2 with beta3?? I reseated audio board and used another USB port on linux box ... I can't see how that changed much... whatever

I'ts intermittent. sometimes WavFilePlayer will run, sometimes hang. maybe doesn't run after a power cycle?

EDIT: removing the audio shield, i ran my WAV to MQS sketch with 100uf cap and 8 ohm speaker to pin 10 and using BUILTIN_SDCARD. That sketch ran reliably and properly re-started if i cycled power. I'll try some more tests with audio shield and WavFilePlayer ...
 
Last edited:
I'll be ready to install test in another couple of hours ...

@manitou - I looked at linked post - Can you clarify what 'hacks' I need to edit after 1.47b3 install to get where you are seeing what you are seeing with WaveFilePlayer?
> As planned I should look to put the T4's ARM_CycCnt version of micros()'s on T_3.6 - that would stop the _irq( Off / On ) when micros is called - be faster - and more precise. Quick Test I did shows the T_3's all support the interrupt retry when reading the millis _isr values - which costs cycles only when that hits.

@WMXZ - Indeed will be interesting to know the release plans for T4 … they are teensy so I have room to get some - but no rush if the first batch sells out :)
 
Does that mean you will start a kickstarter or equivalent around that time as well?

Robin & I recently decided we're *not* doing a Kickstarter campaign for Teensy 4.0.

Assuming there will be no kickstarter for the T4, the question to PJRC (I mean Robin) is if you accept pre-release orders (don't care about final price)?

No, we're not doing pre-orders.


How do you read the version of bootloader (i tried turning on verbose in teensyloader, but didn't see a version number?)
Pretty much have the same question as you - how do you get the version number of the bootloader?

It's in there, buried among a lot of other info.

capture.png



One could argue against erasing EEPROM via the button, but rather add a method to do EEPROM.erase()

Yes, there are a lot of ways it could work. But I have 2 pretty strong reasons why I want it to fully wipe all data.

1: The 15 sec restore is meant to recover from really bad problems we can't really anticipate. Seems unlikely EEPROM data could matter, but then the need at all seems unlikely.

2: Occasionally we get requests for how to completely wipe the hardware. Sometimes it's related to some government standard about hardware being able to purge all user data, probably meant originally for wiping classified secrets, but such standards have a way of becoming a checkbox on some bureaucratic list of requirements


I'ts intermittent. sometimes WavFilePlayer will run, sometimes hang. maybe doesn't run after a power cycle?

Is this on the list in msg #6?

Speaking of that list, there are several lines for the 15 sec restore ending up with a corrupted blink program which Windows won't recognize as RawHID (or Arduino can't upload without pressing the button). Are all those issues solved now?
 
I'll be ready to install test in another couple of hours ...

@manitou - I looked at linked post - Can you clarify what 'hacks' I need to edit after 1.47b3 install to get where you are seeing what you are seeing with WaveFilePlayer?

in audio lib:
play_sd_wav.h: change buffer declaration to uint8_t buffer[512] __attribute__((aligned(0x4)));

in play_sd_wav.cpp: comment out __disable_irq(); before SD.open();

The SD lib was updated to support T4 and to use DMA+IRQ in release 1.46. So it appears that the DMA needs aligned buffers, and since SD lib is doing DMA-IRQ, the disable_irq before SD.open() in AudioPlaySdWav:: play() hangs since SD.open for BUILTIN_SDCARD wants to use DMA interrupts for end of transfer. previous version of SD lib polled on SDHC status for end of transfer. So it's not clear what the "best" solution is -- 1) this hack (not sure why disable_irq is needed before SD.open()), or 2) re-write SD lib again to still do DMA but use polling instead of IRQ, and if we're doing polling, then 3) arguably DMA isn't needed either.

AudioPlaySdRaw with BUILTIN_SDCARD also hangs -- works if you remove __disable_irq() before SD.open() in libraries/Audio/play_sd_raw.cpp

Consider this pull request: https://github.com/PaulStoffregen/Audio/pull/294

EDIT: Paul's FIX 8/11/19 get latest from https://github.com/PaulStoffregen/SD
 
Last edited:
Re: broken WavFilePlayer
Is this on the list in msg #6?

I'll check msg #6 stuff, and add if not there. The WavFilePlayer problem is also popping up in a lot of threads for T3.5 and T3.6 BUILTIN_SDCARD. Started failing with 1.46, me thinks. See previous post (#3171)

EDIT: yes it is in msg #6
 
FYI - I updated to new beta and it looked like it updated the firmware in both the new T4B2R as well as the T4B2 brownout... Note: T4B1 I already have sitting on shelf.

So far I have only done a few tests. Like EEPROM update/dump.

Also Some of our usbhost_t36 stuff (using my Bluetooth WIP branch) and verified I could talk to mouse and keyboard... Right now trying to start figuring out what it would take to support both...
 
OK, beta3 really did update my bootloader. Help verbose says: Board is: Teensy 4-Beta2 (IMXRT1062), version 0.04

So i built WavFilePlayer on 1.47-beta2 system, and now the beta2 version of WavFilePlayer is intermittent too! So I suspect the new bootloader may be effecting stability. (or is my T4B2 too old for updates??) It's a tangled web we weave.
 
Last edited:
I'll test the 15s Restore Windows USB for sure on both White Wire units when I get the download done.

@manitou - if you have a white wire on the underside it should update to that version 0.04 bootloader - AFAIK - no white wire then no update.

Though reading KurtE's note - it looks like his rep-Mod T4 Beta 2 did update?
 
Status
Not open for further replies.
Back
Top