This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

sd_softdevice_disable() not returning during transport shutdown in DFU Bootloader

My setup of the buttonless BLE DFU secure bootloader using SDK15.2 isn't launching the application after a successful OTA package transfer.  Using RTT and breakpoints, I narrowed down the issue to sd_softdevice_disable() inside nrf_sdh_disable_request(). The bootloader code execution disappears inside the SVCALL to disable the softdevice. What could be causing this behavior? 

I'm finding it really difficult to narrow down the cause. My bootloader implementation matches almost identically with the examples except for: using bonds, buttonless DFU service, VS_UUUID_COUNT set to 2, RTT ON and in the same RAM section as the application, flash start/size for the bootloader, using the RC clock source. I set the RAM start and size to:

RAM (rwx) :  ORIGIN = 0x20007978, LENGTH = 0x38688 

Parents Reply Children
  • Thank you for the offer to help debug! I just discovered a few things that seem to have fixed it: First, because I moved the RTT buffer RAM section around, I couldn't get proper logging until I power-cycled the nrf52. Second, I reduced the RTT number of buffers. And the biggest discovery was perhaps that I was enabling mem_manager and compiling the associated files leading to ; I had done that because sdk_config.h in the example has it enabled. 

  • I have a very similar issue while not involving a DFU update...

    nrf_sdh_disable_request() never returns and the system current draw stays around 2.4mA until the watchdog resets the nRF52.


    * Power up reset
    * Start SD and do some measurements
    * Begin sleep mode (disables the SD)
    * Wake on GPIOTE event
    * Start SD and do some measurements
    * Begin sleep mode (disables the SD) disabling the SD never returns.

    nrfjprog --family nrf52 --snr xxxxxx --readregs
    R0:   0x2000FEF7
    R1:   0xE000E100
    R2:   0x40000000
    R3:   0x00010000
    R4:   0x20003920
    R5:   0x20003715
    R6:   0x2000300D
    R7:   0x20002DA4
    R8:   0x20002DA0
    R9:   0x20002D9C
    R10:  0x20002DA8
    R11:  0x00000000
    R12:  0x00000001
    SP:   0x2000FEF0
    LR:   0x00028CD5
    PC:   0x00028CEC
    xPSR: 0x01000000
    MSP:  0x2000FEF0
    PSP:  0x00000000

    nRF5_SDK_14.2.0_17b948a and s132_nrf52_5.1.0_softdevice.hex

    I have inserted a LED flash before and after the call to nrf_sdh_disable_request()

      for (int i=0; i<1000000; i++){
        NRF_GPIO->PIN_CNF[11] = 3<<0;
        NRF_GPIO->OUTCLR = 1<<11;
      }
      for (int i=0; i<1000000; i++){
        NRF_GPIO->PIN_CNF[11] = 3<<0;
        NRF_GPIO->OUTSET = 1<<11;
      }
      
      nrf_sdh_disable_request();
    
      for (int i=0; i<2000000; i++){
        NRF_GPIO->PIN_CNF[11] = 3<<0;
        NRF_GPIO->OUTCLR = 1<<11;
      }
      for (int i=0; i<2000000; i++){
        NRF_GPIO->PIN_CNF[11] = 3<<0;
        NRF_GPIO->OUTSET = 1<<11;
      }

    The first disable functions just fine, the one after the soft reset hangs.
    After a watchdog reset I can repeat the procedure.

    I'm probably going to work around the issue by using a GPIOTE+RTC based wake and resetting the nRF52 using the WD timer.
    The WD timer seem to be slightly cheaper (on avg.) than using the RTC, but since it isn't possible to disable the WD using a software reset I'm probably going that way.

    Regards Visti Andresen

  • Just adding that the problem I was seeing with sd_softdevice_disable() is back again when I try to use multiple DFU transports and I've described it in a new  post.

  • Hi Visti, I assume you are using the clock driver? In that case it's important to note that the driver will attempt to release the LF clock source when the NRF_SDH_EVT_STATE_DISABLED event is raised by nrf_sdh_disable_request(), this is not possible to do when WDT is enabled. The program will therefore become stuck in the while (nrf_clock_lf_is_running()){} loop. You can call nrf_drv_clock_lfclk_request(NULL) after softdevice enable to keep the LF clock on.

Related