Lockable Teensy 4.1 "bricks" after performing the "Lock Security Sketch"

M

markgo

Member
We have purchased a large quantity of Lockable Teensy 4.1 units. Initially we have set the encryption feature on these units by using the "Fuse Write Sketch" program and proceeded to download and test our application. All worked great. Now, it was our intention to lock the key using the "Lock Security Sketch". When that is performed, the Serial Monitor window shows that it was successfully locked. From this point forward the unit becomes unusable "bricked".

Brick definition in this instance: Powering on the unit, it still runs the lock sketch (since that was the last program downloaded). The serial monitor shows that the unit was successfully locked (again). Attempting to download the blink program at this point or any other for that matter, fails, the USB port drops out, (you here the windows USB dropout sound, and Windows indicates an error with the USB port. The USB no longer works again unless you repower the unit. (But again it will not take any program downloads)

I have now bricked 3 units in this way. The first I thought might be a fluke, so I tried it again with another unit. The second one also bricked. The third I tried to reset back to factory defaults first using the 13-17 second reset. It then bricked number 3.

Curiously, when I a start with a virgin Teensy 4.1 right out of the package, and perform the Fuse and Lock commands it works. I can then put my application on the unit successfully. Problem is, I have 24 units with our program on it that are not yet locked. And I am confident that they will brick as well unless I can determine the issue.

Thank you for any help that you can provide.
 
Something is going wrong here, but your Teensy is almost certainly not bricked.

I want to help, but it is difficult to get a clear picture of what's really happening because your description of the problem is heavy on interpretation / analysis while fairly light on clearly stating what actually was observed. I know you're in a problem solving mindset, and that's perfectly natural, but please try to also remember to say what your eyes actually observed. Small details matter.

Earlier you contacted me by email. I described how to save the Help > Verbose Information log from Teensy Loader. This log data shows key details. Please capture this log and share the log file here. The small details in that log sometimes make all the difference.

I believe in one your emails, you mentioned trying the 15 sec restore with more detail than this forum post. Can you tell me again what happened with the 15 sec restore. Please be specific about what your eyes actually saw. Did the red LED blink briefly before you released the pushbutton? Did it turn bright red for a "long" time? Did it later turn off? What happened when the red LED turned off? Did the orange LED again blink? Try to resist the urge to draw conclusions like "bricked" and concentrate on communicating as clearly and precisely as you can about what you actually saw.

Now for a blind guess... over and over on this forum we've seen reports of errors while loading data onto Teensy. They almost always turn out to be flaky USB cables or USB hubs. Another consistent theme is initial disbelief the problem could be a bad USB cable, because it seems to usually work under other circumstances. I have no idea if this really is what you're seeing, but trying with another (ideally short and good quality) USB cable and perhaps even with a different PC is simple, so please give this a try.
 
Okay, I was able to find the gist of the issue, although I cannot fully explain it. Bottom line is, once it is set to locked it can no longer be programmed while the Teensy is in the circuit. (Mind you, that is our circuit, so that is probably not true for all circuits). If I take the Teensy out of the circuit and put it on a bread board with just power supplied, it works. I can program it out of the circuit, then put it back in the circuit and it works. There is apparently some pin that is somehow related to the locking? Before the locking, I was able to program the Teensy all day long in the circuit with no issues. Now that it is locked, I can no longer program it in the circuit.

So now the Teensy units that were "bricked" can now be programmed out of circuit.

Although it would be nice to be able to reprogram the Teensy while it is in the circuit, at least I have a work around. It would be nice, however, to know what pin on the Teensy is related to this issue, so that I know not to use it next time if possible.
 
Just did a quick test regarding pins 24 and 25 on Locked T_4.1 that are pulled high a little (25) or more fully (24) - lighting an LED on those pins.

If Pin #25 is tied to GND the Locked T_4.1 cannot be programmed. The RED LED never lights and the Teensy goes Offline.

Doing the same on an unlocked normal production T_4.1 this is not an issue.
 
I was also going to ask about those pins.

Maybe I misunderstood the description "Attempting to download the blink program at this point or any other for that matter, fails, the USB port drops out" to mean the code begins to load but fails after 1 or more blocks transmitted. That's why I guessed the USB cable issue we've seen so many times on unlocked boards. But now I'm not so sure if the problem is happening before or after the unlock script gets Teensy into regular bootloader mode, or if it's happening earlier while in NXP ROM mode. So much uncertainty. Would be really much better to at least have the Verbose Info log to really know what the PC side saw happen.

I should probably also again mention the NDA with NXP limits how much I can say about secure mode. But without even seeing how far the loading process got, whether Teensy Loader was talking to the Teensy booloader or still dealing with NXP modes, impossible to know whether any of that NXP secret sauce stuff even applies.

At least good to know the problem is "solved", even if we don't know what specific hardware was causing it.
 
Considered adding verbose - but easy to repro ...
No GND<>25 - all is well locked T_4.1

Put GND==25 and push Button with CLEARED verbose [and noted RED LED never visibly lights]:
Code: 
13:19:16.320 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
13:19:16.321 (ports 2): remove: loc=usb:0/140000/0/5/1/4
13:19:16.321 (ports 2): usb_remove: usb:0/140000/0/5/1/4
13:19:16.321 (ports 2): nothing new, skipping HID & Ports enum
13:19:16.352 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
13:19:16.353 (ports 2): nothing new, skipping HID & Ports enum
13:19:16.356 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
13:19:16.356 (ports 2): nothing new, skipping HID & Ports enum
13:19:17.995 (ports 2): purge, name=COM8 (Teensy 4.1) Serial, loc=usb:0/140000/0/5/1/4, age=1.675 sec
13:19:38.536 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
13:19:38.537 (ports 2): nothing new, skipping HID & Ports enum
13:19:38.538 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
13:19:38.539 (ports 2): nothing new, skipping HID & Ports enum
13:19:38.568 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
13:19:38.569 (ports 2): nothing new, skipping HID & Ports enum
13:19:38.645 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
13:19:38.645 (ports 2): nothing new, skipping HID & Ports enum
>> it seems to have something present on USB - repeat changes showing in above and Windows notes 'USB connected not nice...'
1711484764869.png


Note: pulling 24 or 25 to +3.3V does not affect upload.
 
Yes, I just got back from testing, and when pin 25 is held to ground, it cannot be programmed when the unit is locked.

I haven't yet tested to see if that will affect my application, as I am using pin 25 as an address line. Does anyone think there is a problem with that?

Thanks for the help everybody.
 
markgo said:
I haven't yet tested to see if that will affect my application, as I am using pin 25 as an address line. Does anyone think there is a problem with that?
Click to expand...
Pin #24 and #25 during programming receive some level of 3.3V - enough to light an LED DIM or Bright. Not seen on other edge pins.
That has been noted if not documented and needs to be considered in use of those pins.

AFAIK: This is the first exploration of trouble uploading found when pin #25 is held LOW preventing programming on a LOCKED Teensy.

<edit>: A T_4.0 does not have those same pins routed to the edge and does not display similar behavior - but there are many bottom pins untested.
 
FYI - I was testing the app and the address pin (digital 25), appears to work correctly both in reading and writing. (pheww!)

Thanks defragster!
 
Should new designs that intend to use a lockable Teensy avoid use of pins 24 & 25?

@defragster how did you think to check these pins in post #4? Are they mentioned somewhere in a different thread?
 
shawn said:
Should new designs that intend to use a lockable Teensy avoid use of pins 24 & 25?

@defragster how did you think to check these pins in post #4? Are they mentioned somewhere in a different thread?
Click to expand...
pins #24 and #25 are fully functional when not programming. But if Button pressed or doing an upload they do get some level of 3.3V so they can't be used for a device that would turn on or activate uncontrolled in that case. And at this time if p #25 is held to GND the Teensy cannot be programmed if the T_4.1 is Locked.

PJRC sent a test board with LED's on ALL edge pins. Sometime after receiving that it was noted that pins 24 and 25 light those LED's during programming - or anytime the RED bootloader LED is on.

On seeing this thread that LED Board was placed into a breakout allowing the LEDs to be seen and then 3.3V and GND connected to those pins provided the posts #4 && #6 test case as observed.
 
This post Jan 31,2022 not the first but it was first found: ... more on that thread ...
defragster said:
Indeed I have seen this. Not gotten an answer to my questions, and I have not seen it noted or addressed anywhere on the forum.

Bootloader V 1.07 for MCU 1062's ( 4.x or MicroMod ) - NEW with TD 1.56 triggers Pin #24 as seen while the bootloader chip is in active control:
> whenever button is pressed and in bootloader
> or during UPLOAD when Bootloader is active

Teensy with 1062 ( 4.x or MicroMod ) using bootloader before V 1.07 activate Both pins #24 and #25 as above while the bootloader is active.

As seen here: This behavior does NOT happen during a normal power on boot, only when the bootloader is active.

NOTE: Testing here was with an LED on pins 24 and 25. When they are held HIGH the LED is bright, then when the Teensy 'boots' and starts after an upload the LED's are powered but very "DIM" - it seems being held high with low current keeper voltage?

Given the nature of the bootloader being involved, this can only possibly be solved with an update to the bootloader.
Click to expand...
 
Last edited:
Looking at : https://github.com/KurtE/TeensyDocuments/blob/master/Teensy4x Pins.xlsx { Thx @KurtE }

24/A10AD_B0_121.12
25/A11AD_B0_131.13

These pins [AD_B0_12, AD_B0_13] are common to T_4.1 and T_MM and backside T_4.0 in respective locations.

Confirmed a Locked T_4.0 with GND==P#25 (on bottom side) repeats the above noted behavior as the T_4.1: Goes offline on Button.

Teensy SFun MicroMod: Pin #25 on ATP is SDA1 { Thx @mjs513 }
T_MM Lockable (with KEY INSTALLED) but NOT locked: GND==PIN #25 can program ["VerifySecure.ino.ehex" will actually be used]
T_MM Lockable AND locked: GND==PIN #25 cannot program, T_MM goes offline on Button
> not sure if there is another LOCKED unit not found - but this one NOW locked
> Did not upload 'LockSecureMode.ino.hex' with GND==25 in case it would fault the in progress locking
 
Seems as it relates to Locked 1062 it may not be open to change and info limited by secure mode NDA - but this was noted on another thread:
PaulStoffregen said:
Also to confirm what Defragster said, there is a known issue with Lockable Teensy when locked into secure mode, where driving pin 25 low prevents entry into bootloader mode, even when pressing the pushbutton. This only applies to Lockable Teensy and can never occur with standard Teensy.
Click to expand...
Hopefully the 1062 Teensy pages and the bootloader chip will get notes on Pins 24 and 25 to prevent user issues on T_4.0, T_4.1 and T_MM and DIY's using 24==AD_B0_12 and 25==AD_B0_13.
>> Bootloader holds both 24&25 high when engaged
>> Locked 1062 must not hold p#25 low to allow programming
 
I believe I may have a solution for the pin 25 problem on Lockable Teensy.

Try running this program on your Lockable Teensy. You'll need to use Serial Monitor, or delete the wait for Serial Monitor to open.

Code: 
void setup() {
  Serial.begin(9600);
  while (!Serial) ; // wait for serial monitor

  uint32_t boot_config_unwritable = (HW_OCOTP_LOCK >> 2) & 3;
  if (boot_config_unwritable > 0) {
    Serial.println("Boot config is read-only, sorry\n");
  } else {
    Serial.printf("Disable pin 25 during boot\n");
    IMXRTfuseWrite(&HW_OCOTP_CFG6, 0x00000010);
  }
}

void loop() {
}

After this has burned the fuse, hopefully your Lockable Teensy will be able to enter bootloader mode even if pin 25 is low. I tested here on a Lockable Teensy 4.1, but only using a simple wire between pin 25 and GND, not a full system with stuff connected to other pins.

Please let me know if this fully solves the problem with you specific hardware?
 
PaulStoffregen said:
I believe I may have a solution for the pin 25 problem on Lockable Teensy.
Click to expand...
Worked on similar Locked T_4.1 here - just ran GND==25 :: After uploading this p#17 code
Ouput >> Disable pin 25 during boot

Now on that Locked T_4.1 GND==25 does not affect bootloader upload process.

That also turned off the Pin 24 powering during 'Red LED'/Bootloader on the LED board!
 
Perhaps:
Code: 
When locked in secure mode, external circuitry which drives pin 25 low can interfere with entry into bootloader mode. To permanently disable this conflict on pin 25 during boot, run this program.

This also stop both pin 24 and 25 from being driven HIGH when the bootloader is active.

This code which only works on the Lockable Teensy cannot change the pin 24 and 25 going HIGH when the bootloader is active - seems that should be documented as it could cause undesired behavior.
 
defragster said:
Perhaps:
Code: 
When locked in secure mode, external circuitry which drives pin 25 low can interfere with entry into bootloader mode. To permanently disable this conflict on pin 25 during boot, run this program.

This also stop both pin 24 and 25 from being driven HIGH when the bootloader is active.

This code which only works on the Lockable Teensy cannot change the pin 24 and 25 going HIGH when the bootloader is active - seems that should be documented as it could cause undesired behavior.
Click to expand...
I’m trying to figure out the apparent contradiction (maybe it’s the way I’m reading it) in the last two paragraphs. What happens with pins 24 & 25 with lockable/locked, lockable/not locked, and not lockable, after and before running that code?
 
shawn said:
I’m trying to figure out the apparent contradiction (maybe it’s the way I’m reading it) in the last two paragraphs. What happens with pins 24 & 25 with lockable/locked, lockable/not locked, and not lockable, after and before running that code?
Click to expand...
Not sure which two pragraphs? If the posted EDIT "To permanently disable this conflict on pin 25 during boot" was just to make clear the only change/issue is during bootloader usage - at 'runtime' there is no issue with pin 25 and it presents no problems in use - on a lockable Teensy where this code can make the fuse change.

The Original:
Code: 
Pin 25 Issue
When locked in secure mode, external circuitry which drives pin 25 low
can interfere with entry into bootloader mode.
To permanently disable pin 25 during boot, run this program.
versus p#20
Code: 
When locked in secure mode, external circuitry which drives pin 25 low
can interfere with entry into bootloader mode.
To permanently disable this conflict on pin 25 during boot, run this program.

Reading it now this "during boot" should also read perhaps "during bootloader activity"?
Code: 
To permanently disable this conflict on pin 25 during bootloader activity, run this program.

On all shipping Teensy 1062's pins 24 and 25 are driven HIGH during bootloader activity [RED LED on].
On non-Lockable Teensy this cannot be changed and causes no problem loading code.
On a Lockable, but unlocked pin 25 can be held to GND without causing trouble for the bootloader.
On a Lockable Teensy that is LOCKED - without this one time fuse change - holding pin 25 to GND would prevent bootloader operation

However, the Lockable Teensy [Locked or unLocked] can change the FUSE bit using the supplied code and the pins 24 and 25 will no longer be driven HIGH during bootloader operation, AND holding pin 25 to GND will no longer stop normal bootloader operation.
 
It was the last two paragraphs in my quote, beginning with “This also stop” and “This code which only”. Thanks for clarifying.
 
shawn said:
It was the last two paragraphs in my quote, beginning with “This also stop” and “This code which only”. Thanks for clarifying.
Click to expand...
Opps ... These new forum 'partial quotes' "Until Clicked" - I didn't click to expose the rest of the post :(

Seems the rewrite covered the question - hopefully accurately to actual current behavior.
Bummer the pins 24,25 deactivate wasn't found Jan 2022 or sooner - seems having that Off in production could remove any usage issue with them pushing High while in bootloader.
 
You must log in or register to reply here.
Back
Top