Can't communicate with the STM32 after SWD flashing/debugging the NRF51

[theseankelly]

Hey Bitcraze & Forum

Yesterday I spent some time using SWD/JTAG to flash and step through some NRF51 code to take a deeper look at UART timing for syslink messages. I used SWD and the debug adapter (jumper set to 'SWDIO' per the instructions) to flash firmware built with "S110=0 BLE=0". After some hiccups (apparently I needed to power off battery instead of USB? See my forum post from yesterday) it was working great and I measured the timing info I was interested in.

Once done, I sync'ed back to the latest master for the NRF51 firmware and rebuilt (with S110=1 and BLE=1) and did a "make factory_reset" to put the NRF51 back to normal.

I went back to debugging on the STM32 side and discovered that I'm not able to communicate with the chip at all. Here's what I know:

• The M3 LED is not illuminated. I do not know when this started, but I distinctly remember seeing both M2 and M3 illuminated at one point while I was stepping through the power management portion of the NRF51 code.
• The STM32 does not enumerate as a DFU device when I long press the button (but the M2 LED does blink fast as expected)
• OpenOCD cannot communicate with the chip via SWD. The error is "unable to connect to target"

Probably completely unrelated, but this is the second board I have that's showing these same symptoms. The first is discussed in this forum post and resulted from a pretty hard crash, whereas this board was just on my workbench.

Any clues might cause this? Have I provisioned the NRF51 correctly using JTAG or am I missing a step? Do I need to also flash the "crazyflie2-nrf-bootloader" project?

[theseankelly]

I do have one functional board left, so I ran some comparisons. Most pins are the same on the good board and the bad board -- voltage supplies look good in both, the BOOT0 and NRST pins are in the correct states, etc. The only difference I found was on the good board, PA13 (STM_SWIO) is high, but it's low on the bad board. I'm guessing this is just a symptom of the STM32 not executing, and not a cause.

Also, the STM32 chip gets warmer faster on the bad board than on the good board. Kind of seems like I've toasted the STM32 but I don't really see how simply JTAG'ing the NRF51 would have done that...

[arnaud]

Hi,

I just tested to make sure and "make factory_reset" flashes everything back, firmware, bootloader, mbs and stack. Then the STM32 boots correctly. What debug adapter are you using, an ST-link V2?

For DFU there is a trick: I have to click the button once more in order to get the dfu to connect, I am not sure why though.

When M2 is illuminated (normal start), the stm32 is powered and so it should be accessible with SWD.

I agree that I do not see any way to brick the stm32 when debugging the nrf51, not if you did not touch the power management part at least (there is some data pin between the CPUs and if the stm32 is kept OFF when these pin are powered it is not so good to the STM32 GPIO, the firmware is designed in such a way that this does not happen. Even if it happened it is unlikely would burn anything anyway ...).

[tobias]

If you are on windows and use a STLinkV2 the there is a STlink utility SW which is a bit better att getting the STM out of problematic states which I think is what has happened. I'm thinking the DFU mode should work as well though. If Arnaud button trick doesn't work try holding the button and connect USB afterwards.

[theseankelly]

I'm using the STM32 discovery board with a STLink adapter on it. I think it's a V1 and not a V2 -- looks like V2 adapters are cheap on amazon so if V2 offers better features that would help me recover the chip I'll gladly order one.

I've used DFU mode before and also noticed the extra button press - I think because the STM has to be power cycled after the NRF is holding the BOOT0 pin high. I usually just hold the button down before I plug the USB cable in though, as Tobias also suggested.

Unfortunately it doesn't look like DFU works - windows doesn't even detect a new device arrival like it usually does. I also tried the ST-LINK utility after I found a few posts about the STM32 that suggested using "connect on reset" or "hotplug" connection modes, and releasing reset or powering on right after clicking "connect". That doesn't seem to work either. Any other tricks you know of with the st link utility?

That's an interesting point about backpowering the STM32. I didn't change any power management code but I did step through it (my code changes were only to enable the RTC clock to verify the systick interval and measure how long it takes to transmit syslink messages). Is there any chance that flashing components in the wrong order (or if flashing died in the middle) that the chip would be running in some intermediate step where the IO pins are powered but the STM32 is not? I agree that it's unlikely anything would be damaged, but I guess you never know. Unlikely, but if so, it could also relate to why a battery must be connected to flash the NRF51. Backpowering the STM32 might (but probably not..) draw enough current to cause the system to brown out on USB power. Maybe I'll connect a battery through a current meter and see what the draw is while flashing the NRF51 just as an experiment. But again, I'd be pretty surprised if this was enough to brown out and even more surprised if it was enough to damage the STM32.

(edit: I should add I've also tried recovering through the bitcraze VM just to rule out possibility that I've messed up the configuration on my PC - same results for SWD unfortunately)

[theseankelly]

Do you have any more ideas? Are there lower level bootloaders than DFU mode I can put the chip in? I can't bring myself to believe the chip is damaged or bricked simply from debugging the NRF... That seems unlikely right??

[tobias]

hmm, very strange and I'm thinking like you, very unlikely the STM32 would have damaged by debugging the nRF51. Have you checked the current draw, might give some indication but since the STM32 might be in some wired state who knows what the correct current consumption is.

If the STM32 is held in reset all the pins should be in some defined state so maybe it is possible to check for something fishy then? You mentioned the STM_SWIO is high. Would be good to know if it is the STM32 or the nRF51 that is holding it high. If it is the nRF51 that might be the problem. However I think the default state should be high...