Electronic – Relationship between reset pins and SWD functions (ARM Cortex M0)

My SWD program outputs 50 clock cycles, issues the SWD switchover command,

Not accurate:

What could be causing this strange RESET_b behavior?

The reset behavior is normal for an un-programmed chip. It is crashing (main() returns) and being reset by the watchdog timer.

Here are a few general tips:

1. First, check the errata for the part and family. There is nothing worse than wasting days chasing someone else's mistake. Facing a similar issue with a different Freescale chip, I discovered a number of issues it has with high slew rates during power up, especially on the reset pin. High slew rates may very well be causing a latch-up condition for you too.

2. Use any available utility to attempt a mass-erase before further reprogramming.

3. There is a tiny hint of "pins" visible along the vertical perimeter of the chips. Verify continuity between each "pin" and pad/trace/signal, using a needle and microscope, if necessary. Attach one continuity lead to the needle and, pushing toward the center of the chip and sliding downward, the needle will "catch" on the pin.

4. When designing boards for hand-soldering QFN's, extend the pads well beyond the chip boundary. Give yourself enough room to use a regular fine-point soldering iron tip to fix errant pins. Initially, try doubling the pad length.

5. With a small, but obvious, bubble of clean solder filling each pin, get rid of all flux and/or residue. Lightly scrub the chip and board with isopropyl alcohol until bright and shiny.

6. It may be helpful to bake your circuit board (literally) and attempt re-flow on the pre-heated PCB.

7. Lightly pressing down on the chip while hot will make the bubbles bulge out from under the chip slightly. Don't mash down so hard the bubbles overflow underneath the chip and short. Use a fine-point soldering iron to hit each bubble for a second and both the pad and chip will suck it up.

Remember that you don't have to mount your chip perfectly flat and... perfect.. like the machine does for it to work. It's OK if the chip is sitting up high and looks awkward; it's actually much easier to microscope in from the edge when it's elevated.

I wouldn't lose hope just yet, because the only way to brick them for good (with software) is to permanently secure them in a non-functional state. Although that could occur on a blank chip due to programming interruption/glitches, it is unlikely.

Discharge energy of a 100nF capacitor at 3.3V is roughly 550 nanoJoules. That's not a lot.

The debug interface will probably have strong drivers or an open collector that will cope with this. It has to be fairly robust in order to survive ambient electrostatic discharge while not plugged in. If that's a recommended circuit or one used by someone else then I'm sure it will be fine. If you're really worried put another one of those 22R in series with it; you can swap it later for 0R on the PCB if you want.