SWD, Reset line, and RTT

[Jandyman]

Hello,

We have an nrf51822 system where disconnecting the battery is problematic, and the sharing of the reset line between SWD and reset function has been a real source of problems for us. It's time for me to understand the subtleties a little better.

I found a post where it explains how to get the reset line out of debug mode and into standard reset functionality, which we need to do operate in normal mode in our system. I have been doing this programmatically in my code by modifying the reset register in the power peripheral, but it would be preferable to do this with a programming tool instead. Is this possible?

One thing that I don't know how to do is get back from standard reset functionality to debug mode. The Eclipse IDE and Segger setup seems to do this for me sometimes, but some times the chip gets wedged and we have to take things apart and disconnect the battery to restore function. It would great to understand what might be happening here and how to avoid this situation.

Finally, I have implemented a comprehensive logging facility using RTT over the SWD, which I've used to great effect in debug mode, where the GDB server provides an adapter for JLinkRTTClient to use. It would be great to hook up to the chip already running in "normal" (non-debug) mode and monitor via RTT, but so far when I try to do this it seems to stop the program and the whole system gets jammed up. Is it possible to tap into SWD RTT without "disturbing" a running program? And if so, what tool would I use to do this?

Thanks immensely for any help, especially since I've asked several questions here.

- Andy

[Kenneth]

Hi,

I have been doing this programmatically in my code by modifying the reset register in the power peripheral, but it would be preferable to do this with a programming tool instead. Is this possible?

That is the way to go. You should enable pin reset by writing to the NRF_POWER->RESET register in beginning of main(). This will ensure that pin reset always works (even in debug mode). The only way to exit debug mode is power cycle or pin reset. The only way to enter debug mode is a clock cycle on SWDCLK.

but some times the chip gets wedged and we have to take things apart and disconnect the battery to restore function.

Sounds like you are having issue to get a proper reset. Try to connect a 1Mohm between SWDIO and GND and let me know if you see the problem again. This should act as an additional reset source if you are having VDD connection or slow VDD ramp up issues. Also add a 1kohm between SWDCLK and GND if you haven't already.

Is it possible to tap into SWD RTT without "disturbing" a running program? And if so, what tool would I use to do this?

Unfortunately no.

Best regards,
Kenneth

[Jandyman]

Thanks. On the second question, I know I'm getting a proper reset signal on the reset line because I've looked at it on the scope. Remember that VDD is high the entire time in this scenario since we are connected to a battery. If I take the unit apart and disconnect and reconnect the battery, I can get back into debug mode. But your comment about the other line is interesting. Does getting back into debug mode from normal mode involve using both pins in concert?

The problem we've been fighting is that I need to set the NRF_POWER->Reset pin in code for release code so the reset pin behaves normally, but sometimes I can't get back to debug mode once this is done, and I can't program the chip either. The battery disconnect seems to be the only thing that works at that point. I haven't figured out what the exact trigger for this is, because it doesn't always get wedged. It is very mysterious. And it is becoming a giant problem

[Kenneth]

Hello,

There is no specific relationship between the two pins, other than they share an SWD interface. Have you tried my suggestion yet? 

The 1kohm pull down resistor on SWDCLK should already be part of the reference schematic, so the only thing "new" compared to the reference schematic in my suggestion should be to add a 1Mohm pull down on SWDIO.

Best regards,
Kenneth