Teensey Loader Problems

c172jeff

Well-known member
Hi,
I have been having problems loading new code onto my Teensey 4.1. I have tried several different sample programs and 2 known/working usb cables.

The log from a verbose snapshot from the loader( Version 1.55) is below. I get the same behavior even when compiling/loading the basic blink program? What is going wrong? I have used this board before and it was recently sitting for a couple of months. The board worked before/is genuine.

In the log below.. I see the line "23:31:18.259 (loader): Opps, NXP ROM in open mode, but we do not yet have code for this case :("

What does this mean, how do I close the NXP ROM, I assume that has something to do with the problem I am having.

Note, when I press the load button on the Teensey 4.1 , I get messages on the log below/activity, proving that the cable is good, but an anomaly is encountered.


23:29:50.709 (loader): file changed
23:29:50.727 (loader): File "C:\Users\Jeffrey\AppData\Local\Temp\arduino_build_195947\Example2_OutputToProcessing.ino.hex", 33792 bytes
23:29:50.730 (loader): File "Example2_OutputToProcessing.ino.hex". 33792 bytes
23:29:50.733 (post_compile 3): Begin, version=1.55, high-res time
23:29:50.740 (loader): remote connection 11120 opened
23:29:50.742 (loader): remote cmd from 11120: "comment: Teensyduino 1.55 - WINDOWS (teensy_post_compile)"
23:29:50.742 (post_compile 3): Sending command: comment: Teensyduino 1.55 - WINDOWS (teensy_post_compile)
23:29:50.743 (loader): remote cmd from 11120: "status"
23:29:50.751 (post_compile 3): Status: 1, 0, 0, 14, 0, 0, C:\Users\Jeffrey\AppData\Local\Temp\arduino_build_195947\, Example2_OutputToProcessing.ino.hex
23:29:50.751 (post_compile 3): Sending command: dir:C:\Users\Jeffrey\AppData\Local\Temp\arduino_build_195947\
23:29:50.752 (loader): remote cmd from 11120: "dir:C:\Users\Jeffrey\AppData\Local\Temp\arduino_build_195947\"
23:29:50.754 (loader): remote cmd from 11120: "file:Example2_OutputToProcessing.ino.hex"
23:29:50.755 (post_compile 3): Sending command: file:Example2_OutputToProcessing.ino.hex
23:29:50.768 (loader): File "C:\Users\Jeffrey\AppData\Local\Temp\arduino_build_195947\Example2_OutputToProcessing.ino.hex", 33792 bytes
23:29:50.770 (loader): File "Example2_OutputToProcessing.ino.hex". 33792 bytes
23:29:50.774 (loader): remote cmd from 11120: "status"
23:29:50.782 (post_compile 3): Status: 1, 0, 0, 14, 0, 0, C:\Users\Jeffrey\AppData\Local\Temp\arduino_build_195947\, Example2_OutputToProcessing.ino.hex
23:29:50.782 (post_compile 3): Sending command: auto:eek:n
23:29:50.782 (loader): remote cmd from 11120: "auto:eek:n"
23:29:50.784 (post_compile 3): Disconnect
23:29:50.807 (loader): remote connection 11120 closed
23:29:51.138 (post_compile 4): Begin, version=1.55, high-res time
23:29:51.140 (loader): remote connection 11124 opened
23:29:51.143 (loader): remote cmd from 11124: "comment: Teensyduino 1.55 - WINDOWS (teensy_post_compile)"
23:29:51.144 (post_compile 4): Sending command: comment: Teensyduino 1.55 - WINDOWS (teensy_post_compile)
23:29:51.146 (loader): remote cmd from 11124: "status"
23:29:51.155 (loader): remote cmd from 11124: "dir:C:\Users\Jeffrey\AppData\Local\Temp\arduino_build_195947\"
23:29:51.156 (post_compile 4): Status: 1, 1, 0, 14, 0, 0, C:\Users\Jeffrey\AppData\Local\Temp\arduino_build_195947\, Example2_OutputToProcessing.ino.hex
23:29:51.156 (post_compile 4): Sending command: dir:C:\Users\Jeffrey\AppData\Local\Temp\arduino_build_195947\
23:29:51.158 (loader): remote cmd from 11124: "file:Example2_OutputToProcessing.ino.hex"
23:29:51.159 (post_compile 4): Sending command: file:Example2_OutputToProcessing.ino.hex
23:29:51.172 (loader): File "C:\Users\Jeffrey\AppData\Local\Temp\arduino_build_195947\Example2_OutputToProcessing.ino.hex", 33792 bytes
23:29:51.176 (loader): File "Example2_OutputToProcessing.ino.hex". 33792 bytes
23:29:51.183 (loader): remote cmd from 11124: "status"
23:29:51.193 (post_compile 4): Status: 1, 1, 0, 14, 0, 0, C:\Users\Jeffrey\AppData\Local\Temp\arduino_build_195947\, Example2_OutputToProcessing.ino.hex
23:29:51.193 (post_compile 4): Disconnect
23:29:51.210 (post_compile 5): Running teensy_reboot: "C:\Program Files (x86)\Arduino\hardware\teensy\..\tools\teensy_reboot.exe" teensy_reboot.exe "-board=TEENSY41" "-port=fake serial" "-portlabel=(null)" "-portprotocol=(null)"
23:29:51.215 (loader): remote connection 11124 closed
23:29:51.225 (loader): remote connection 11124 opened
23:29:51.252 (reboot 6): Begin, version=1.55, high-res time
23:29:51.252 (reboot 6): location = fake serial
23:29:51.252 (reboot 6): portprotocol = (null)
23:29:51.252 (reboot 6): portlabel = (null)
23:29:51.252 (reboot 6): Emulated serial devices will be tried first
23:29:51.252 (reboot 6): LoadLibrary cfgmgr32 ok
23:29:51.252 (reboot 6): LoadLibrary ntdll ok
23:29:51.254 (reboot 6): nothing new, skipping HID & Ports enum
23:29:51.258 (loader): remote connection 11128 opened
23:29:51.264 (reboot 6): Disconnect
23:29:51.289 (loader): remote connection 11128 closed
23:29:51.296 (loader): remote connection 11124 closed







<After Button Press>



23:31:17.864 (ports 2): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
23:31:17.869 (ports 2): nothing new, skipping HID & Ports enum
23:31:17.882 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
23:31:17.883 (ports 2): nothing new, skipping HID & Ports enum
23:31:17.960 (loader): stop ignoring usb:0/1D0000/0/1/5
23:31:18.045 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
23:31:18.045 (ports 2): nothing new, skipping HID & Ports enum
23:31:18.212 (loader): handle 2b40
23:31:18.214 (loader): Device came online, code_size = 100
23:31:18.215 (loader): Board is: NXP IMXRT1062 ROM
23:31:18.218 (loader): begin operation
23:31:18.233 (loader): File "C:\Users\Jeffrey\AppData\Local\Temp\arduino_build_195947\Example2_OutputToProcessing.ino.hex", 33792 bytes
23:31:18.236 (loader): File "Example2_OutputToProcessing.ino.hex". 33792 bytes
23:31:18.239 (loader): set background IMG_ONLINE
23:31:18.250 (loader): nxp_write: success
23:31:18.254 (loader): nxp_write: success
23:31:18.257 (loader): HAB open mode, bootcfg=80018
23:31:18.259 (loader): Opps, NXP ROM in open mode, but we do not yet have code for this case :(
23:31:18.261 (loader): start ignoring usb:0/1D0000/0/1/5
23:31:18.264 (loader): end operation, total time = 0.043 seconds
23:31:18.270 (loader): redraw timer set, image 79 to show for 3000 ms
23:31:18.287 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
23:31:18.287 (ports 2): nothing new, skipping HID & Ports enum
23:31:21.270 (loader): redraw, image 9





Please advise,
Jeff
 
Hi,

Is there an update to this issue? I'd like to load firmware, but cannot. I see the loader error at line
23:31:18.259

"(loader): Opps, NXP ROM in open mode, but we do not yet have code for this case " and suspect that is the cause.

Should I be waiting for a loader update or is my board damaged?

I am hoping there is something I can do to set the board in a state that the loader then works.

Please advise,
Thanks,
Jeff
 
Not sure if @PaulStoffregen saw this - seems only he would recognize that odd 'open mode' error.

Has the 15 second Restore been done? That might restore normal function.

> with T_4.1 powered
-> Press and hold the Button
-> watching for a Flash on the USB end RED LED at about 15 seconds
-> When FLASH is seen release the button and watch

After the Flash and release the RED LED should light and remain lit for some ~30 seconds in some fashion while the onboard FLASH is formatted and other settings restored.

When the RED LED goes out the Teensy should be Restored to Factory Blink

--> Do these steps proceed as indicated?

Was the T_4.1 purchased from PJRC or a distributor? Saw a post linking to eBay offering half priced T_4.1's
 
I tried the 15 second restore but it did not work as expected.

I did see the short quick flash after about 15 seconds of pressing the button, but the device never showed a stead red light to indicate it was reloading the blink program.

The factory blink program was never reloaded/installed.

The device was purchased on May 8th from Amazon.
Jeff
 
Anything soldered or connected to the teensy?

Does it look like the posted PJRC images of a T_4.1 in exact detail? Any missing parts?
 
The headers are soldered to it.
It worked perfectly the last time I used it a few months ago. It has sat idle.
It was last used to drive a SmartMatrix board that connected to an RGB panel. That is probably still running.

There appears to be no missing parts. It appears to have some life in it based on some LEDS flashing.

It can communicate with the Windows 10 PC. By that I mean, when the loader asks for the button to be pressed, the Windows 10 PC knows when the button is pressed, but then errors out.
Jeff
 
Hello, Does anyone have advice as to how I can revive my Teensey? Is there a way to set it in a state that I can then program it. Thanks,Jeff
 
Did you resolve? I have a couple of Teensy MicroMods not responding, one did report the Opps message before giving up. completely.

I did see the Opps message on another one, was able to recover by holding down the boot button during powerup and releasing afterwards.
 
Did you resolve? I have a couple of Teensy MicroMods not responding, one did report the Opps message before giving up. completely.

I did see the Opps message on another one, was able to recover by holding down the boot button during powerup and releasing afterwards.

I did not resolve this. My Teensey still has this problem. I'm wondering how much to really invest in Teensey system if this problem tends to happen and there is no way out. I was thinking I could solder some wires and close the NXP memory to get it going?? Then it would be normal.

Yet, I did buy a new Teensey and that works fine. Hopefully, a fix can revive my dead one.
 
@c172jeff - Sorry, I missed this thread earlier.

First, to answer about "Opps, NXP ROM in open mode, but we do not yet have code for this case", it means your Teensy wasn't able to access the flash memory chip to boot up. Instead it went into a special fallback mode using on the on-chip ROM, because it couldn't access any other memory.

This result by itself doesn't necessarily mean the hardware has failed. It's possible to get "NXP ROM in open mode" by programming invalid data into the first 512 bytes of the flash memory, which are used at boot time to configure optimized flash access. Normally this shouldn't happen if you only upload from Arduino. But it can happen if you copy a HEX file (without the matching ELF file) meant for a completely different board and use File > Open in Teensy Loader to open it and then program it onto your Teensy. Teensy Loader can only detect if the hardware was really meant for your board if it finds a matching ELF file... which is always present when using Arduino.

You can also get "Opps, NXP ROM in open mode" if you edit the bootdata.c file and change the contents of the FlexSPI_NOR_Config[] array. Again, not something pretty much anyone does... but the error by itself can mean wrong data got stored in that part of the flash chip.

But this error while doing the 15 sec restore is a pretty strong indication the flash chip or connectivity between the flash chip and processor has failed.

I tried the 15 second restore but it did not work as expected.

I did see the short quick flash after about 15 seconds of pressing the button, but the device never showed a stead red light to indicate it was reloading the blink program.

Did you buy this Teensy 4.1 direct from PJRC or from a distributor?
 
Thanks Paul, I bought the board from Amazon. Are you selling through Amazon?

Is that a valid distributer? Where should I be buying the boards from?
I guess my Teensey must be damaged.
 
Thanks Paul, I bought the board from Amazon. Are you selling through Amazon?

Is that a valid distributer? Where should I be buying the boards from?
I guess my Teensey must be damaged.


We do have official distributors who sell through Amazon.

Would you send me an email with your order details. We would like to arrange to send you a replacement.
robin at pjrc

-Robin
 
Thank you Robin, That's really nice. I will private message you the order details. I printed a pdf from my Amazon Account of the purchase/address of the my order. It was sold through a seller on Amazon names "3DMakerWorld, Inc."
 
Hi, I get the same error on a Teensy 4.0, no improvement even after the 15s procedure:
Code:
22:21:19.441 (loader): HAB open mode, bootcfg=80018
22:21:19.454 (loader): Opps, NXP ROM in open mode, but we do not yet have code for this case :(

Strangely enough it kind of worked ok the first couple times I programmed it with blink example and with my own ones.
Tested only with teensyduino 1.53 and 1.56.
Any thought ?
I think I ordered it on PJRC the weeks after its release, if that somehow could help..
 
I uploaded to a Teensy MicroMod yesterday and ended up with:
Code:
23:07:18.303 (loader): HAB open mode, bootcfg=80018
23:07:18.306 (loader): Opps, NXP ROM in open mode, but we do not yet have code for this case :(
Loader Verbose presents this on power up connect - then goes to the two Led BLink

Powering from USB Battery unit:
Now on fresh power up holding the button at 15 seconds it flashes - then goes into 2 Flash Blink:
Code:
[URL="https://www.pjrc.com/store/ic_mkl02_t4.html"]2 Blinks = NXP JTAG Not Responding[/URL]
No communication is working! The 2 likely causes for this problem are improper power startup sequence, or a problem with any of these connections between the MKL02 and IMXRT chip:

After that while powered the 2 blink persists - even while pressing the button.

Paul - here is the loader verbose log from that time: View attachment T_MM_OPPS.zip
 
Last edited:
Code:
08:03:33.361 (loader): Bootloader upgrade: 1.05 -> 1.07
Do you see this every time?

Hi Frank, no. That was a rare instance where it showed up from what I can see. Tried for the 10 last minutes but no success. Noticing now also in the same file:
Code:
08:03:33.750 (loader): Bootloader update: 0% of estimated 8 seconds, wait=0
[COLOR="#FF0000"]08:03:33.986 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL[/COLOR]
[COLOR="#FF0000"]08:03:33.988 (ports 2): nothing new, skipping HID & Ports enum[/COLOR]
08:03:34.021 (loader): Bootloader update: 3% of estimated 8 seconds, wait=2
08:03:34.030 (loader): handle 660
08:03:34.041 (loader): Bootloader update finished, 0.2 seconds
08:03:34.050 (loader): Board is: NXP IMXRT1062 ROM, version [B]0.00[/B]
08:03:34.067 (ports 2): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
08:03:34.068 (ports 2): nothing new, skipping HID & Ports enum
08:03:34.130 (loader): flash, block=0, bs=1024, auto=1
08:03:34.136 (loader): program: write error

Do you think red lines are causing this ?
 
We can only speculate here, based on no firm knowledge. We do not know when which text will appear.
The only one who can say something about it is himself, as there is no documentation.
This is "closed source" from Paul's loader application.

But I'm especially surprised about the last line.
Code:
08:03:34.136 (loader): program: write error

For me, it indicates (pure speculation) that there is a problem with the Flash chip. Maybe it is defective, or the connection is bad.
And then, why the bootloader update? Id should have happened before - you tried it very often, right? That is the reason for question - if you had seen it before. Of course, it should happen only once.

Without Paul answering here, we won't get anywhere.

There only one thing I know: Uploading a defective program (or a write error) results in the message "Board is: NXP IMXRT1062 ROM"

Then, I can say - I had a T4.1 wich showed a similar symptom with flash chips soldered to the bottom. Resoldering solved it.
But that was just a similar symptom (Edit: "similar" here means: weird effects with the additional flash). It does not have to mean anything.

So.. wait for Pauls answer. (I wouldn't wait too long for it, though. Do not be surprised if no answer comes here.)
 
Last edited:
Finally some progress about this message:
Code:
08:03:33.361 (loader): Bootloader upgrade: 1.05 -> 1.07

shows up at least after these steps done in that particular order:
-arduino ide opened but teensyloader closed
-verify button in arduino ide
-teensy reset button pushed once teensyloader has started
 
I could imagine a powering problem. Have you tried an other usb cable? Do you use a passive (unpowered) hub?
 
@johnbob: @Frank B makes a good reminder about his QSPI Flash chip. Have you soldered anything to the bottom of the T_4.1 chip area?

Indications are Paul will be looking at this in coming days ...

Looking at the two p#16 log files - the one with 'Opps' is short and not showing any other instances for bootloader version - that should be one time and done - the first time 1.56 loader is used. In post #1 TD 1.55 was still in use.

I just mailed the T_MM unit from p#15 to Paul - it will be there Saturday and that is a Task at the top of his list to investigate the 'Opps'. Apparently, he's neck deep in 'time critical software' work hoping to complete that by the weekend.

He previewed the p#15 5,500 line log and the text presented doesn't show an issue with the logged messages.

The 2 Blink code (p#15) from bootloader, as Frank's p#19, suggests the reason that message would be presented is failure of the onboard Flash chip accessing startup code to make the 1062 run.
 
I guess there is something really wrong... the bootloader update should happen exactly one time. Never, after the first (and only one) successful update.
 
I guess there is something really wrong... the bootloader update should happen exactly one time. Never, after the first (and only one) successful update.

...Perhaps check the board visually. Is there a missing part, maybe? A missing capacitor could cause this..
 
First, the easy question:

Code:
08:03:33.986 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
08:03:33.988 (ports 2): nothing new, skipping HID & Ports enum

Do you think red lines are causing this ?

No, these aren't the cause of any problem. At most they can be a symptom of some problem. But often they don't mean anything at all.

Windows has a very simple way of notifying programs of hardware changes. Or you could use words other than "simple", like "unsophisticated" or "primitive".

By contrast, programs on MacOS which want to be informed of hardware changes create a specification of which things they want to monitor using IOServiceAddMatchingNotification, with functions you want called when those devices are added or removed. Then a "run loop" function is called, which will make callbacks your functions when the hardware changes you said you want to monitor have occurred. Linux has similar functionality with libudev1, with functions udev_monitor_filter_add_match_subsystem_devtype() and udev_monitor_enable_receiving(). On Linux the device change notifications are delivered via a traditional Unix file descriptor number which works with Unix functions like select() and poll(), so you can build whatever function callback or response mechanism you like. The libudev1 library provides functions for actually reading whatever data format is actually used. Both of these systems are very efficient because the actual checking for whether the device change info matches your desired criteria happens in kernel space and I/O events are only delivered to the specific processes needing them. (or maybe on Linux other mechanisms like dbus are used... I'm not sure)

Microsoft didn't do anything like this. Windows uses the window message system that is traditionally meant for passing GUI events like mouse clicks, keystrokes, window raise/lower/redraw, and other GUI stuff. You can't tell Windows which type of hardware change your program wants to monitor (or if you can, I don't know how... but remember, we're compatible all the way back to Windows XP, so not using any API's added in Vista or later). You can only sign up hear or ignore the WM_DEVICECHANGE message, which gets broadcast to ALL programs whenever ANY hardware or device-level change occurs. The message carries only minimal info, whether the nature of the change was something added (DBT_DEVICEARRIVAL), something already present changed in some way (DBT_DEVNODES_CHANGED), or something disconnected (DBT_DEVICEREMOVECOMPLETE). Then you have to use Setup API or other mechanisms to detect whether the change was anything you actually wanted. Windows can't even tell you about the change. You have to read a list of all devices (which can at least be limited to one type of hardware) and compare against the list you got previously. The teensy_ports.exe program does this in a few steps, first with SetupDiGetClassDevs using the GUID_DEVINTERFACE_USB_DEVICE class, so it can quickly determine whether the change was anything it needs to know. The logged message "nothing new, skipping HID & Ports enum" means it got info from that first step which indicates whatever hardware changed was not one of the Teensy vid/pid numbers it tracks. It probably printed this because it saw the USB device wasn't Teensy, but rather NXP ROM.



Now, the difficult question.....

Code:
08:03:34.050 (loader): Board is: NXP IMXRT1062 ROM, version 0.00

First, I need to communicate honestly and clearly that I do not have every answer. There are unknowns here...

I do know of 3 distinctly different scenarios which can cause the hardware to appear as "NXP IMXRT1062 ROM", though I can't know for certain these 3 are all possible cases. But I can say "version 0.00" is meaningless, so please disregard the version number.

1: If the flash memory has invalid boot data in the first 512 bytes, or an invalid IVT data at address 60001000, the chip will fail to boot and will appear this way. Normally good data is always present after every upload, unless you edit {Arduino}/hardware/teensy/avr/cores/teensy4/bootdata.c, or if you upload a HEX file not meant at all for Teensy 4 (without a .elf file present, so Teensy Loader skips the check that your hardware matches the compiler's intention).

2: When Lockable Teensy is locked into secure mode, pressing the pushbutton will cause the chip to initially boot up as the NXP ROM. Teensy Loader 1.55 or later should automatically handle this scenario if you have a EHEX file, and if NXP ROM is found to be in secure mode rather than in open mode.

3: A failure of the flash memory, but the main processor still functioning, can also cause the hardware to appear as NXP ROM mode. For example, completely desoldering the flash chip will do this. As far as the processor is concerned, the situation looks the same as if the flash chip is blank (case #1).

There could be other possible cases. This hardware is very complex.

You'll see the latest version of Teensy Loader says "but we do not yet have code for this case :(" for open mode. In a future version, I'm planning to add code which will try to diagnose whether the problem was scenario #1 or #3 or possibly #4+ which are not yet known.

Unfortunately, I can't promise any specific time frame for that code to be written. I can tell you I am right now working on support for Arduino's new CLI and IDE 2.0 software and will not be able to do much else for at least the rest of this week. I do consider this a high priority, so I intend to fill in that diagnostic code before returning to projects like MTP.

I know this uncertainty isn't very satisfying. I really wish I had a better answer now, but at this moment the very best I can do with this lengthy message with as much info as I currently know. Hopefully it helps at least a little?
 
Last edited:
Back
Top