Unbrick MAX32660 that is programmed to drive SWD pin?

Question

I thought I was being clever by remapping my UART output to the SWD output pin. I'm not a fan of debuggers (they don't scale). I assumed I could just reprogram my MAX32660 by holding it in reset, such as one does with AVRs for example.

Well it turns out that neither OpenOCD nor PyOCD wants to talk to the MAX32660 while it's in reset. For example, PyOCD says "Device state is Reset". I can't even halt the device.

It's hard to believe that there is no way to get the SWD function back. But in this thread about another Arm that (similarly to the MAX32660) can reassign the SWD pins, they claim that the device can only be reprogrammed if there is sufficient delay between the start of reset vector code and the time that it reassigns the SWD pins.

I am using a MAX32660 EVSYS to program the part. Can this programmer (which only supports SWD) unbrick the part? Could a JTAG programmer unbrick the part?

Answer 1

Chris's solution (first comment) worked for me.

If you have the debugger setup to drive the hardware reset a command such as "reset halt" may do it. Then you erase the offending flash. This works on ST not sure about your part but it is likely as the debug functionality comes from ARM, it is the flash part that is vendor. Beware the debugger may not be driving the hardware reset when you think it is... Try a scope without any target connected to verify. Also see if the vendor flash loader tool has any special modes, ST's has a "connect under reset" in an options menu.

Answer 2

I wanted to second Chris's solution and add some follow-up for those using Keil uVision (V5.36.0.0):

I disabled the SWD by setting the GCR_SCON.sw_dis field to 1 via the following interface provided by Maxim's sample "GPIO (MAX32660_EVKIT)" project:

MXC_GCR->scon |= MXC_S_GCR_SCON_SWD_DIS_DISABLE;

Which results in the "SWD/JTAG Communication Failure" error below:

Then to bring the SWD back online, under the MAX32660_EVKIT CMSIS-DAP Debugger Settings I changed the Debug => Connect & Reset Options => Connect: "Normal" to "under Reset".

Screen grabs of the relevant settings below:

Answer 3

I assumed I could just reprogram my MAX32660 by holding it in reset, such as one does with AVRs for example.

yeah, no. What the reset pin means and what a programming mode is depends on what the manufacturer designs it to be!

Since modern ARM MCUs tend to be much, much nicer than AVRs ever where, many of them have a boot pin with which you can select a bootloader to be started and wait for commands on e.g. UART and USB (!). That bootloader can then only be disabled by the engineer by writing to a specific address in flash.

This is a very common method to program in production. Another very common method is indeed using SWD and loading firmware that, like yours, simply disables SWD if you don't want people to have a debug interface. (I don't think "debuggers don't scale" is a true statement hence. In fact, SWD is a pretty nice thing and allows for a lot of in-system programmability, eg. when you want to update the firmware of your power controller on your PC/laptop mainboard. This scales to a couple million units...)

Anyway, your IC most definitely has such a bootloader; you should be able to use it to load new firmware onto your device. Read the MAX32660 Bootloader User Guide (UG6471).

device can only be reprogrammed if there is sufficient delay between the start of reset vector code and the time that it reassigns the SWD pins.

Exactly. The trick they do is: set up a debugger to continously try to debug, and then release the reset. There's no guarantee this works on the first try, so you might need to try multiple times.

You could try releasing the reset pin and immediately clocking the SWD clock.

If that doesn't work on the first try, variate the timing between these two.

Do that as often as it takes before it works. Might take a couple thousand tries until random variations make that work.

Or, you could use an external clock instead of a crystal oscillator to clock the core, and simply stop clocking it after clocking one clock cycle after releasing reset, then try to do SWD; if that doesn't work, try two clock cycles, and so on.

Neither is something an eval board does out of the box. You'd want something like an FPGA board and have to write extensive gateware or use e.g. Scanlime's existing glitching framework.