nrf52832 stops getting firmware via SWD after a while

RE: nrf52832 stops getting firmware via SWD after a while

Kenneth — Tue, 04 Oct 2022 09:08:37 GMT

Weird indeed.

- Is there any discrepancy between the supply voltage on the custom board vs. what the jlink support? E.g. if you are using a DK for SWD the target supply voltage must be around ~3V.
- You have connected common ground between the jlink and target board yes?
- And is there any difference if you force the pin reset pin to VDD?

Kenneth

RE: nrf52832 stops getting firmware via SWD after a while

oguzhanERG — Tue, 04 Oct 2022 07:33:25 GMT

I am using sdk 14.2, i am using latest tools. For debugging i am using IO/CLK pins after i trying to enter debugging the MCU stops working untill power reset.

RE: nrf52832 stops getting firmware via SWD after a while

Kenneth — Wed, 28 Sep 2022 07:34:36 GMT

Seems like a bug of some sort, any help in updating to the latest nrf command line tools?
https://www.nordicsemi.com/Products/Development-tools/nrf-command-line-tools/download

What nRF5 SDK is this?

Kenneth

RE: nrf52832 stops getting firmware via SWD after a while

oguzhanERG — Tue, 27 Sep 2022 13:09:47 GMT

SWD problem started after we implement rtt reading(SEGGER_RTT_GetKey).

  while(SEGGER_RTT_HasKey()) 
  {
    rtt_input_buffer[dataLength] = SEGGER_RTT_GetKey();
    if(rtt_input_buffer[dataLength] == '+')
    {
      rtt_callback(rtt_input_buffer, dataLength);
      dataLength = 0;
      memset(rtt_input_buffer, 0, RTT_INPUT_BUFFER_LENGTH);
    }
    else
    {
      dataLength++;
      SEGGER_RTT_WriteString(0, "RTT\n");
    }
  }

It feels like the code stucks in this while and can not use swd after this point ?

nrfjprog --recover not working. most of the devices are working fine btw.

RE: nrf52832 stops getting firmware via SWD after a while

Kenneth — Tue, 27 Sep 2022 12:28:25 GMT

Hello,

I don't think there is any direct relationship between the two observations:

- 1 device stop working and when re-connect battery device start working again

- 2 but not the SWD interface

About 1 I think it could be an assert, in which case (if you are debugging) the project may end in the fault handler, and if you have built with debug it will stay there until a reset is triggered. In a real product I suggest to build with release build and not debug, to ensure that the product instead reset if there is an fault. Though you should likely look into trying to find the cause of what is hanging in your project, or possible look at the fault handler to find where the code may be asserting.

About 2 this may be related to APPROTECT enabled, in which case only an eraseall or recover may make the SWD interface operation again. E.g. does 'nrfjprog --recover' make the SWD interface work again?

Kenneth