Teensy 3.6 custom design resetting itself regularly

[Brianh]

I've posted before about this but still haven't figured it out and have some new info. Quick recap, we've designed several of our own boards using Teensy 3.6 design and Arduino, mostly with no issues. One out of every 10 or 15 boards we make does not connect to Windows 10/Arduino right from first power up (no code downloaded). Looking at the reset pin with a scope shows it low for about 75us, then released for about 3us, at which time it goes low again and repeats this cycle. With some boards pressing the program button results in reset high continuously as it should be but the oscillator is not operating and no USB communication (obviously, with no oscillator). On other boards a button press does not change the reset pin behavior. I've tried the 15s button press too - behavior is the same. We've had success in these cases by replacing the processor and/or bootlloader, but obviously that's quite a bit of work even though we use the QFPs. I concluded that there is some corrupt code in the MK66 that is causing it to reset itself almost immediately after coming out of reset (I've cut the reset track to the MK66 and see the same thing, so I know it's the MK66 asserting reset). We do have a voltage monitor on the reset line (MCP130T-270) which holds reset low for ~350ms at power up. I thought that might be interfering with bootloader/MK66 communication at power up but then I read this thread which indicates that it's OK to use a Vcc monitor: https://forum.pjrc.com/threads/53176-Teensy-3-6-Reset-Pin?highlight=15+seconds

I'm pretty confident in our hardware - the Teensy schematic is almost identical and we have ground and power planes, thorough decoupling, very stable 3.3V, etc. Love to hear any thoughts.
Thanks

 

[jonr]

> low for about 75us
Is this the same for good and bad boards? If so, I think it suggests that the bootloader is successfully programming the MK66. You could dig deeper to verify.

Failure to start the crystal probably results in a MK66 resetting itself. Or having nothing programmed (the result if the bootloader can't control MK66 reset).

The MCP130T-270 is easy to remove.

I once had an issue with power that looked perfect with a voltmeter but was not stable. But by far, the problem is usually soldering.

 

[Brianh]

No, reset is only cycling like this on a bad board. Attached is a scope shot. On a good board as soon as the bootloader releases reset it goes high and stays there. That's an interesting point about the oscillator not starting causing the MK66 to reset itself - I'll check deeper into that. But the fact that it is only out of reset for <3us makes me unsure because I don't think that's enough time for the MK66 to determine that it's not running. I did remove the MSP130 on a bad board with no help - it seems like once it's in this mode it's unrecoverable. I've checked the 3.3V rail with a scope several times and see very little ripple and it has very good load transient response. Thanks for the ideas.

 

[jonr]

Sounds like you need input from Paul .

Don't know, but 3 usec seems like long enough to do many checks, including operation of a 16mhz crystal.

I am curious if the duration of reset can be used to differentiate between a) the boot-loader can't communicate with the main MCU to program it and b) the boot-loader successfully loaded code but which of various problems occurred in the main MCU. If not, SWD data line activity should confirm a).