On many microcontrollers or other devices without JTAG/SWD functionality, there is a reset pin which when low unconditionally and asynchronously forces everything into a known state. On devices with JTAG or SWD functionality, however, things seem to be more complicated since it's possible to perform some JTAG/SWD functions while the reset pin is asserted.

I have some Freescale KL15Z-based boards which include the SWD pins on a connector with the reset line and some other diagnostic I/O pins. Occasionally when connecting or disconnecting a cable, the parts seem to get into a weird state such that even reset won't kick them out. I'm wondering if some stray pulses on the SWD pins might be putting the device into an "ignore the reset pin" state. I have found that when using the debugger, I seem to have frequent difficulties getting the devices to reset reliably; I don't know if the issues may be related.

What is the relationship between the reset pin and the SWD functionality? Conceptually it would seem most helpful to have a design where any falling edge on reset would be guaranteed to actually reset everything, and SWD communications which were supposed to happen before user code startup could be performed with reset held low, but I don't think that's how the Freescale KL15Z chips actually work. What's the best way to solve such reset-related problems with the Freescale or similar parts?

  • \$\begingroup\$ Two observations short of an answer: The Kinetis chips will drive their own reset line, which can be interesting. I've also seen a K20 get stuck in a tight reset loop - producing a sawtooth output on its reset line, where the fix (under openocd) was to issue "kinetis mdm mass_erase" while the reset input is asserted. After that it became possible to release the reset and manipulate it normally. \$\endgroup\$ – Chris Stratton Jun 8 '15 at 16:18
  • \$\begingroup\$ I had a similar looking issue, but the root cause was not reset pin. (I had an active-low bootloader pin being pulled to GND via an LED.) Could something like that be your problem? \$\endgroup\$ – Frederick May 25 '16 at 18:16
  • \$\begingroup\$ @Frederick: I don't remember what the problem turned out to be on the Freescale part. I did some time later have some fun with an Atmel part (also Cortex-M0) which turned out to be a consequence of a really badly designed watchdog. My code relied upon the "watchdog early warning interrupt" to wake it up periodically, but on the Atmel part feeding the watchdog will suspend its operation until the action is synchronized between the bus clock and the 32768Hz watchdog clock. If the processor goes into deep sleep mode before that happens, the watchdog can remain suspended indefinitely. \$\endgroup\$ – supercat May 25 '16 at 18:34

The SWD side of the debug interface takes a power-on-reset, but it is basically a shift register which triggers AHB accesses to the rest of the system after observing a specific input pattern/number of shifts. There is is a degree of error detection on the sequence, it is fairly implausible that you would observe spurious accesses and not have the interface lock out waiting for a new initialisation. (Of course, the debug host might silently reconnect in this case since the protocol is designed to be error tolerant).

The debug interface can also request a CPU reset (through an internal DP register access rather than requesting an AHB access). This is typically fed to the on-chip reset generation, but again should not be able to glitch as the result of noise on the SWD input.

The reset pin is generally not a full power-on reset, and probably won't reset either the SWD side of the debug interface, or the flash controller.


Reset pin is often not needed, because controller is possible to reset using debug registers.

Only one case when is necessary is connection under reset, this mean that if SWD signals are shared with other functionality on board (forexample SWDIO or SWDCLK is set as output), then only way to access MCU is to put MCU in to reset (at this moment are some debugging registers accessible over SWD) and set HALT/STOP program flag with debug registers over SWD, then leave reset pin and at this moment it is possible to flash MCU.

  • \$\begingroup\$ Many devices need to be able to unconditionally reset independent of previous state (e.g. to recover after an unexpected glitch). If the reset pin cannot be relied upon for that purpose, a device which is powered continuously through a battery that's awkward to remove or replace may require some other means of interrupting power. \$\endgroup\$ – supercat May 8 '17 at 2:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.