Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 2 1 2 LastLast
Results 1 to 25 of 27

Thread: Teensey Loader Problems

  1. #1

    Teensey Loader Problems

    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_bu ild_195947\
    23:29:50.752 (loader): remote cmd from 11120: "dir:C:\Users\Jeffrey\AppData\Local\Temp\arduino_b uild_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: auton
    23:29:50.782 (loader): remote cmd from 11120: "auton"
    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_b uild_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_bu ild_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_rebo ot.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

  2. #2
    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

  3. #3
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,547
    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

  4. #4
    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

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,547
    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?

  6. #6
    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

  7. #7
    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

  8. #8
    Senior Member
    Join Date
    Feb 2020
    Posts
    118
    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.

  9. #9
    Quote Originally Posted by TeensyWolf View Post
    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.

  10. #10
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,526
    @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?

  11. #11
    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.

  12. #12
    Administrator Robin's Avatar
    Join Date
    Oct 2012
    Location
    PJRC Global Headquarters
    Posts
    325
    Quote Originally Posted by c172jeff View Post
    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

  13. #13
    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."

  14. #14
    Junior Member
    Join Date
    Jan 2022
    Location
    EUROPE, FRANCE
    Posts
    5
    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..

  15. #15
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,547
    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:
    2 Blinks = NXP JTAG Not Responding
    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: T_MM_OPPS.zip
    Last edited by defragster; Yesterday at 05:15 AM.

  16. #16
    Junior Member
    Join Date
    Jan 2022
    Location
    EUROPE, FRANCE
    Posts
    5
    Here the logs fullLogsT4.zip

  17. #17
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,658
    Code:
    08:03:33.361 (loader): Bootloader upgrade: 1.05 -> 1.07
    Do you see this every time?

  18. #18
    Junior Member
    Join Date
    Jan 2022
    Location
    EUROPE, FRANCE
    Posts
    5
    Quote Originally Posted by Frank B View Post
    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
    08:03:33.986 (ports 2): WM_DEVICECHANGE DBT_DEVICEARRIVAL
    08:03:33.988 (ports 2): nothing new, skipping HID & Ports enum
    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 0.00
    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 ?

  19. #19
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,658
    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 by Frank B; Yesterday at 09:34 PM.

  20. #20
    Junior Member
    Join Date
    Jan 2022
    Location
    EUROPE, FRANCE
    Posts
    5
    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

  21. #21
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,658
    I could imagine a powering problem. Have you tried an other usb cable? Do you use a passive (unpowered) hub?

  22. #22
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,547
    @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.

  23. #23
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,658
    I guess there is something really wrong... the bootloader update should happen exactly one time. Never, after the first (and only one) successful update.

  24. #24
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,658
    Quote Originally Posted by Frank B View Post
    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..

  25. #25
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,526
    First, the easy question:

    Quote Originally Posted by johnbob View Post
    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 by PaulStoffregen; Yesterday at 10:57 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •