Micromod and Micromod Teensy

Nope, both cables show my phone as a data device.

Plugged ATP/Teensy Micromod #2 in...no problem.

Tried reseating the the Teensy in #1 ATP board. Didn't help.

I swapped the processor between boards thinking on would work and one would not well wrong. Now both work????

Wierd. Could be the end connector tolerance vs the connector tolerance. Possibly good old header pins are more reliable.

Anyways I will try swapping back and see what happens.

Thanks
 
@TeensyWolf - might do a quick 15sec Restore test to see if it completes. That SFUN link suggested some might have left without a bootloader flash?

Ok, did that, no effect. Held down BOOT for 15-20 seconds, both after powerup and during powerup.

I scoped the BOOT signal to the MicroMod, U3, Pin10, it's high, goes low when I push BOOT pushbutton, so the signal is getting there.

This seems like the bootloader is not programmed.

For reference, I initially bought 2 from Sparkfun, then 5 from DigiKey. I'm not sure exactly where this one came from.
 
Ok, did that, no effect. Held down BOOT for 15-20 seconds, both after powerup and during powerup.

...

Assume the T_MM Yellow bootloader LED was monitored for a flash at about 15 seconds as the cue to release the Boot Button and begin the Flash erase and restore where the LED goes Yellow ON for some 30+ seconds before returning to Blue LED blink?

- just did that here on the one I unpacked yesterday and it did htat.
 
Assume the T_MM Yellow bootloader LED was monitored for a flash at about 15 seconds as the cue to release the Boot Button and begin the Flash erase and restore where the LED goes Yellow ON for some 30+ seconds before returning to Blue LED blink?

- just did that here on the one I unpacked yesterday and it did htat.

No LED change on the MM.

Now the MM won't blink blue.

Was on C to C cable. Just tried on a USB A to USB C Cable. No change.
 
Odd, it won't come blinking Blue factory blink without test/install of that blink sketch - which goes along with bootloader required in some fashion? At least when PJRC does them ...

... and with that the 15 sec Restore should then work. At least it does here on the SFUN unit just opened, that code had to have been written to the FLASH above the EEPROM area and made safe.

If a simple Blink in IDE is done with 'Verify' build and Teensy Loader open - and open and clear the Verbose:
> hold Boot Button while plugging and release
> If TLoader sees anything that may make it diagnosable.
-> it might program
-> or not show
-> or show with error connecting/programming
 
Well, swapped the the boards and the original combintation will not communicate. Swap them back and it works fine.

Seems to be a mechanical interfacing issue between the processor edge connector and the ATP board connector?

Weird!

Thoughts?

Thanks

Bruce
 
Well, I now have 2 boards that won't yellow blink. It used to. I was happily developing with it.

I tried your hold boot button during powerup (in Sparkfun Data logging board). On device # 1, nothing.

Device #2:

Code:
15:10:55.204 (ports 5): Begin, version=1.55, high-res time
15:10:55.204 (ports 5): LoadLibrary cfgmgr32 ok
15:10:55.204 (ports 5): LoadLibrary ntdll ok
15:10:55.207 (ports 5): callback 0024
15:10:55.207 (ports 5): callback 0081
15:10:55.209 (ports 5): callback 0083
15:10:55.210 (ports 5): hWnd = 2099756
15:10:55.214 (ports 5): nothing new, skipping HID & Ports enum
15:15:20.237 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
15:15:20.247 (loader): remote connection 2040 opened
15:15:20.251 (ports 5): nothing new, skipping HID & Ports enum
15:15:20.256 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
15:15:20.258 (ports 5): nothing new, skipping HID & Ports enum
15:15:20.289 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
15:15:20.290 (ports 5): nothing new, skipping HID & Ports enum
15:15:20.487 (loader): handle 6e8
15:15:20.487 (loader): Device came online, code_size = 100
15:15:20.492 (loader): Board is: NXP IMXRT1062 ROM
15:15:20.492 (loader): begin operation
15:15:20.502 (loader): File "C:\Users\win\AppData\Local\Temp\arduino_build_76374\Blink.ino.hex", 18432 bytes
15:15:20.507 (loader): File "Blink.ino.hex". 18432 bytes
15:15:20.512 (loader): set background IMG_ONLINE
15:15:20.517 (loader): nxp_write: success
15:15:20.522 (loader): nxp_write: success
15:15:20.527 (loader): HAB open mode, bootcfg=80018
15:15:20.527 (loader): Opps, NXP ROM in open mode, but we do not yet have code for this case :(
15:15:20.527 (loader): start ignoring usb:20000/0/0/1/4
15:15:20.527 (loader): end operation, total time = 0.030 seconds
15:15:20.537 (loader): redraw timer set, image 79 to show for 3000 ms
15:15:23.538 (loader): redraw, image 9
15:16:10.541 (loader): Auto Button event
15:16:10.541 (loader): Auto mode: disabled

Device #2 spit this out once, now won't show any life.

This is concerning me as I have a project shipping soon and designed these parts in. I'm going to order a bunch more to have a spares, but I will also pickup an ESP or STM micromod for a Plan B if this keeps happening.
 
Well, I now have 2 boards that won't yellow blink. It used to. I was happily developing with it.

I tried your hold boot button during powerup (in Sparkfun Data logging board). On device # 1, nothing.

Device #2:

Code:
15:10:55.204 (ports 5): Begin, version=1.55, high-res time
15:10:55.204 (ports 5): LoadLibrary cfgmgr32 ok
15:10:55.204 (ports 5): LoadLibrary ntdll ok
15:10:55.207 (ports 5): callback 0024
15:10:55.207 (ports 5): callback 0081
15:10:55.209 (ports 5): callback 0083
15:10:55.210 (ports 5): hWnd = 2099756
15:10:55.214 (ports 5): nothing new, skipping HID & Ports enum
15:15:20.237 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
15:15:20.247 (loader): remote connection 2040 opened
15:15:20.251 (ports 5): nothing new, skipping HID & Ports enum
15:15:20.256 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
15:15:20.258 (ports 5): nothing new, skipping HID & Ports enum
15:15:20.289 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
15:15:20.290 (ports 5): nothing new, skipping HID & Ports enum
15:15:20.487 (loader): handle 6e8
15:15:20.487 (loader): Device came online, code_size = 100
15:15:20.492 (loader): Board is: NXP IMXRT1062 ROM
15:15:20.492 (loader): begin operation
15:15:20.502 (loader): File "C:\Users\win\AppData\Local\Temp\arduino_build_76374\Blink.ino.hex", 18432 bytes
15:15:20.507 (loader): File "Blink.ino.hex". 18432 bytes
15:15:20.512 (loader): set background IMG_ONLINE
15:15:20.517 (loader): nxp_write: success
15:15:20.522 (loader): nxp_write: success
15:15:20.527 (loader): HAB open mode, bootcfg=80018
15:15:20.527 (loader): Opps, NXP ROM in open mode, but we do not yet have code for this case :(
15:15:20.527 (loader): start ignoring usb:20000/0/0/1/4
15:15:20.527 (loader): end operation, total time = 0.030 seconds
15:15:20.537 (loader): redraw timer set, image 79 to show for 3000 ms
15:15:23.538 (loader): redraw, image 9
15:16:10.541 (loader): Auto Button event
15:16:10.541 (loader): Auto mode: disabled

Device #2 spit this out once, now won't show any life.

This is concerning me as I have a project shipping soon and designed these parts in. I'm going to order a bunch more to have a spares, but I will also pickup an ESP or STM micromod for a Plan B if this keeps happening.

Ok you sure its not the ATP carrier board? Makes no sense - I have 3 boards - 1 was development and 2 from Sparkfun and all worked in the ATP carrier.
 
Odd indeed. Prior posts with NEW boards here: ATP and T_MM noted cable issue.

JUST TRIED:
> That ATP with T_MM - and 'bad' cable. Would fail over half the time of 12 connects.

> Same cable to Display Carrier with 2nd T_MM : 100% connect.

--- SWAP the T_MM's

Same 'bad' cable: BOTH POWERED up 100% over 5 times.

<EDIT>: Returned the T_MM's to the Carrier they were coded for. Using same 'bad' cable plugged and unplugged 6 times , flipped USB-C connector and repeated 6 times. Twelve for Twelve that T_MM in ATP came up properly.

:: Suggests the T_MM module was not well/properly seated in the connector on the carrier?

> Assure T_MM fully inserted - with USB unplugged

> Secure screw into Carrier while holding the T_MM in place

Any change?


During Beta we had just one T_MM and 3-5 Carrier boards [ ATP, Display, ML, DataLogger, PJRC Breakout ] so some few times that Beta T_MM got moved - and these startup issues never showed up.
 
Unsure what it could be. I've been using the Sparkfun Datalogging board for my reference, but developing in my custom PCB. I feed it 3.3V from LDO, made from 5V DC/DC brick, being fed 12V, at some point, this will be fed by 48V, but for now benchtop supply.

I diode OR my 5V with the USB 5V so I can program without 12V active.

schematic.jpg
 
Unsure what it could be. I've been using the Sparkfun Datalogging board for my reference, but developing in my custom PCB. I feed it 3.3V from LDO, made from 5V DC/DC brick, being fed 12V, at some point, this will be fed by 48V, but for now benchtop supply.

I diode OR my 5V with the USB 5V so I can program without 12V active.

Is the issue with the ATP Board or your custom board?
 
When they bricked, I was developing in the custom board, I wasn't using the Sparkfun board for anything but troubleshooting the MM.
 
Is the issue with the ATP Board or your custom board?

I'm using my custom board mostly. I have 3 devices up & running for over 24 hours, so that's good. I'm not doing any code development presently or much rebooting, just letting them run.

So right now, isolated to 2 devices that are bricked. Hopefully it stays this way.
 
I'm using my custom board mostly. I have 3 devices up & running for over 24 hours, so that's good. I'm not doing any code development presently or much rebooting, just letting them run.

So right now, isolated to 2 devices that are bricked. Hopefully it stays this way.

Guess trying to isolate whether you got bad MM's or something in your design like a power spike or something. Would have tried testing to make sure the MM was good in the ATP carrier. Not good at electronic design but would look at the power hookup section of the atp carrier just to make sure. Maybe someone else could help more on that end.
 
Guess trying to isolate whether you got bad MM's or something in your design like a power spike or something. Would have tried testing to make sure the MM was good in the ATP carrier. Not good at electronic design but would look at the power hookup section of the atp carrier just to make sure. Maybe someone else could help more on that end.

I'll update as i learn more. One MM certainly was working for a few days. The other i never was able to get windows to assign a COM port.
 
The other i never was able to get windows to assign a COM port.

Like all Teensy, the default mode is HID, not serial. So if you are only looking for a COM port while troubleshooting, it might be working and you would not see the HID interface because it's not a COM port.

While troubleshooting, always keep the Teensy Loader window open and visible on your desktop. Turn off Auto mode, so it doesn't immediately reprogram the board. If you see the "Press Button... " message disappear and a bright image of MicroMod in the window, then you'll know your PC has detected the hardware.
 
@TeensyWolf, yes, Yes, the missing USB port is not good and there is much more uncertainty - It can also be the board. Or the MM2 connector. But you had the other MM running - so it is most likely the Teensy MM itself. I have read that several had such problems. Maybe there is a quality problem?
 
Just to toss a few more data points (or more confusion) into this. We just ordered 50 MM teensy from Digikey last week and out of the first five we have taken out for testing 2 did not blink and eventually showed up in windows as 1062 USB so we assumed the bootloaders were missing (this was with a SF ATP board). Even the other ones seem to randomly detect the HID and often only show up as comm ports and need the button pressed to flash; although that may well be because we are swapping these amongst several computers in the lab as we test various things. We have the first samples of our own carrier board that uses a USB B connector instead of USB C and so far it seems to pick up as expected and program without issue? We haven't spent any real time on these anomalies as we have a few larger issues we are tracking down. These are going in a short run product for us though and we will need to eventually run this down and test the whole batch that came in. If it does end up that some left SF without the bootloader programmed will the 15 second program button re-flash work on a fresh bootloader chip?
 
Just to toss a few more data points (or more confusion) into this. We just ordered 50 MM teensy from Digikey last week and out of ...

Wonder if this post by Paul Teensey-Loader-Problems - and ref to the Teensy Loader Verbose as noted in that thread's p#1 show anything in common on the ones not looking right?

> properly seat a good one in carrier - open that Help / Verbose
> Push button and watch the verbose.

> Repeat with one that failed before
> Any response in the Verbose?
-> anything odd in the verbose - give it a post for Paul's review
 
Easiest to test with a Windows machine that makes the chime sounds when USB devices are connected and removed. Testing any other way requires watching for HID devices, which can be done, but it's often an error-prone process because most PCs have at least a few other HID connected at all times.

If you hear the chime sounds when pressing or releasing the Boot button, that's a sure sign the bootloader is present.

When you press and hold the button for ~13 seconds, you should see a quick flash on the LED which indicates the beginning of a 4 second window where releasing the button will initiate the 15 sec restore process. That quick LED blink at approx 13 seconds is also a sure sign the bootloader is present.

The restore process feels like it takes forever, though it's probably only about 2 min. Sparkfun uses a much larger flash chip and the process is slow. But when it finally does complete, the other LED should be blinking and your PC should detect MicroMod as RawHID (not serial - NO COM PORT). If you're working with other people who know Arduino boards, it's important to tell them to look for HID. People who only know of COM ports will often mistakenly believe the hardware is not working when they don't see a COM port.

If you do get the quick LED blink at 13 seconds, but then the restore process doesn't run, and the USB always comes up as NXP's HID (vid: 1FC9, pid: 0135), that's a pretty sure sign the flash chip or the wiring between the processor and flash chip has failed.

You can also have NXP's HID on perfectly good hardware if you program an invalid HEX file. If the first 512 bytes doesn't contain proper flash settings, or the IVT data is invalid, you'll get NXP's HID. Teensyduino should always produce valid HEX files (unless you edit the core library code) and Teensy Loader uses the matching ELF file to prevent programming a HEX file build for a different board. But if you just copy the HEX file without the matching ELF, or create a HEX file some other way, and use Teensy Loader to write it, you can end up with NXP's HID. While not an issue with today's MicroMod boards, at some point in the future (when people may find this message by search) code security will become supported. If you have locked security and load a EHEX file encrypted with the wrong key, or an unencrypted HEX file (Teensy Loader would normally refuse to do these things to a locked board so you'd have to go to special effort), you would also get NXP's ROM for those security violations. The chip only boots from flash if those data structures in the first part of the flash have valid data, and in locked secure mode only if cryptographically signed by the authorized key. You can get NXP's HID with perfectly good hardware if the flash chip contains unbootable data.

No bootloader will give you an absolutely lifeless Boot button (as would a hardware issue where it simply isn't connected or the button is defective) with no Windows chimes on press or release, and no quick LED flash after holding for 13 seconds. The Program signal which the Boot button shorts to ground has an internal pullup by the bootloader, so seeing 3.3V on that pin is also a good sign the bootloader is present. If the pin is connected to the bootloader chip but not bootloader code is present, you'll often see the pin "float" around 0.25 volts. Because it's high impedance floating, touching the wires will affect it. If you see that floating voltage and pressing the button does make it go to 0, (and your multimeter naturally reads 0 with the leads in your hands but not touching any circuitry) that's also a sign the hardware is connected and the bootloader is probably missing.

Hopefully this long-winded explanation helps you get to the bottom of what's wrong. I'm really curious to hear anything you may learn?
 
Last edited:
Using this in a Windows CMD.exe - DOS box : "{local install}\hardware\tools\teensy_ports.exe"

Starts teensy_ports.exe that will display info on the connect state and type of connected Teensy.
Code:
{
  "address": "usb:0/140000/0/6/3",
  "online": true,
[B]  "label": "COM33 (Teensy MicroMod) Serial",[/B]
  "vid": "16C0",
  "pid": "0483",
  "iserial": "849287",
  "boardName": "Teensy MicroMod",
  "protocol": "Teensy"
}
{
  "address": "usb:0/140000/0/6/1/3",
  "online": true,
  "label": "COM36 (Teensy 4.1) Serial",
  "vid": "16C0",
  "pid": "0483",
  "iserial": "970638",
  "boardName": "Teensy 4.1",
  "protocol": "Teensy"
}
{
  "address": "usb:0/140000/0/6/1/4",
  "online": true,
  "label": "COM11 (Teensy 4.1) Serial",
  "vid": "16C0",
  "pid": "0483",
  "iserial": "100038",
  "boardName": "Teensy 4.1",
  "protocol": "Teensy"
}

Then pushing T_MM 'Boot' Button shows that changing that as:
Code:
{
  "address": "usb:0/140000/0/6/3",
  "online": true,
  "label": "[no_device] (Teensy MicroMod) Bootloader",
  "vid": "16C0",
  "pid": "0478",
  "iserial": "849287",
  "boardName": "Teensy MicroMod",
  "protocol": "Teensy"
}
{
  "address": "usb:0/140000/0/6/3",
  "online": true,
[B]  "label": "hid#vid_16c0&pid_0478 (Teensy MicroMod) Bootloader",[/B]
  "vid": "16C0",
  "pid": "0478",
  "iserial": "849287",
  "boardName": "Teensy MicroMod",
  "protocol": "Teensy"
}


@Paul going to ADD and repost this on td1,56 beta thread re the Locked T_4.1.
 
What to do if there is no bootloader in T_MM?

No bootloader will give you an absolutely lifeless Boot button (as would a hardware issue where it simply isn't connected or the button is defective) with no Windows chimes on press or release, and no quick LED flash after holding for 13 seconds. The Program signal which the Boot button shorts to ground has an internal pullup by the bootloader, so seeing 3.3V on that pin is also a good sign the bootloader is present. If the pin is connected to the bootloader chip but not bootloader code is present, you'll often see the pin "float" around 0.25 volts. Because it's high impedance floating, touching the wires will affect it. If you see that floating voltage and pressing the button does make it go to 0, (and your multimeter naturally reads 0 with the leads in your hands but not touching any circuitry) that's also a sign the hardware is connected and the bootloader is probably missing.

Hopefully this long-winded explanation helps you get to the bottom of what's wrong. I'm really curious to hear anything you may learn?

Hi, I have flashed T_MM (Teensy MicroMod on Sparkfun ATP Board) with an empty code via arduino just to check connection, it did work..But now the T_MM program led blinks two times repeatedly (blink blink...........................blink blink........................blink blink...), No windows chime is heard.. nothing.. it just blinks. Tried to reset it by holding boot 13s.. it didnt work.
Did i brick my T_MM?😢
What is the indication of blinking program led?


After reciveing the board ,I made all the connections and plugged the usb, The stat LED blinks.. and i flashed the exact empty code with arduino:

void setup() {
}

void loop() {
}
I flashed and process was fine.

But now after unplugging the usb and plugging it, It is not detected by the computer, infact even arduino ide. No windows indication was there.
But the Micromod program LED blinks twice every 3s (blink blink...........................blink blink........................blink blink...), it is not responding to the boot press, i cant flash anything to the board now, i think my action have deleted the bootloader due to which it is not getting detected.

I dont know what to do..
 
Last edited:
Hi, I have flashed T_MM (Teensy MicroMod on Sparkfun ATP Board) with an empty code via arduino just to check connection, it did work..But now the T_MM program led blinks two times repeatedly (blink blink...........................blink blink........................blink blink...), No windows chime is heard.. nothing.. it just blinks. Tried to reset it by holding boot 13s.. it didnt work.
Did i brick my T_MM?😢
What is the indication of blinking program led?


After reciveing the board ,I made all the connections and plugged the usb, The stat LED blinks.. and i flashed the exact empty code with arduino:

void setup() {
}

void loop() {
}
I flashed and process was fine.

But now after unplugging the usb and plugging it, It is not detected by the computer, infact even arduino ide. No windows indication was there.
But the Micromod program LED blinks twice every 3s (blink blink...........................blink blink........................blink blink...), it is not responding to the boot press, i cant flash anything to the board now, i think my action have deleted the bootloader due to which it is not getting detected.

I dont know what to do..

Screenshot (167).jpg
This is the attachment of my set up. I is a Micromod Teensy On a sparkfun All the pin dev board.
 
The bootloader on a Teensy cannot be deleted as it resides on a separate physical processor chip.

As far as 2 Blinks = NXP JTAG Not Responding it is noted on that page. Not that that offers a solution except perhaps power: Unplug and physically reset/rescrew the T_MM, try another cable or plug into a powered Hub or different USB port?

Was the 'empty code' sketch built with USB Type: USB Serial? When the RED LED blinks the sketch is not running - but would need to be built with USB Serial (the default) to register with the computer.

I just received a new T_MM and ATP board this month I have been using without trouble with a few sketches and more reprogramming.

I just uploaded the default IDE NEW empty sketch here and it is working fine. Not the first T_MM here - there are 4 on the desk. One of the other three may be a pre-Release Beta unit from way back when that I expect still works.
 
I have also done this, the Teensy Micro Mod is not detecting. Think i accidentally erased the bootloader. Is there any way to reflash the boot loader?
 
Back
Top