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

Secure DFU bootloader problem nRF52832

I have a strange problem with the secure bootloader.

After a succsessful DFU update of firmware, the firmware starts, but resets after a short while (about a second).

Using RTT log, I can't see any reason for the reset (with no calls to APP_ERROR_HANDLER). When I reprogram the firmware (with same firmware) with the IAR Embedded Workbench IDE, the firmware runs fine.

I have performed a readback of the entire memory after DFU, and after programmed with IAR, and the only difference in flash is at address 0x0007E000 - 0x0007E07, as I understand is in the MBR segment. Before and after a DFU, these locations are blank (0xff). After programmed with IAR, these locations are set to something. As I understand, these data tells where the the bootloader starts. I have tried setting these locations manually, but it does not make any diffence. The reset behaviour is the same with and without data in these locations.

The device I am using on my board is NRF52832.

What I have done:

  • Implemented buttonless DFU in the firmware using the "ble_app_buttonless_dfu" example project from SDK12.2.0 as template
  • Modified the bootloader_secure example project in SDK12.2.0, basically removed the button and LED handling, as my board does not have any buttons.
  • Generated new public key and replaced "dfu_public_key.c" (nrfutil keys display).
  • Built the bootloader_secure example project.
  • Merged the .hex file from the bootloader_secure example project with softdevice S132 ver.3.0.0 .hex file (mergehex).
  • Erased chip and programmed the resulting .hex file from the merge (nrfjprog).
  • Reset the chip (nrfjprog).
  • Generated private key.
  • Made a firmware update .zip package (nrfutil pkg generate) with correct key.
  • DFU updated the chip with firmware using nRF Connect for Android. nRF Connect reports success.

After DFU update, the device behaves as described above. After (re)programmed with IAR, the device works fine.

Is there something I have forgot?

Regards, Jan

Parents Reply Children
  • Hi Darren,

    Watchdog is off, as far as I can see, both in bootloader and application.

    I have problems checking if hardfault interrupt is triggering. When I try to debug from bootloader, I get error ELF/DWARF Error: Unsupported .debug_info format version: 4. If I debug from application code, application does not reset after flashing, as I described above.

  • Jan,

    I also experienced the ELF/DWARF Error and at the time I couldn't determine the cause. I now think it maybe due to the uECC library not having debug symbols but that is a theory.

    Try this for the Hardfault handler:

        /** Redefine the hard fault processing handler */
    void HardFault_process(HardFault_stack_t *p_stack)
    {
        /* These are volatile to try and prevent the compiler/linker optimizing them
        away as the variables never actually get used.  If the debugger won't show the
        values of the variables, make them global my moving their declaration outside
        of this function. */
        volatile uint32_t r0;
        volatile uint32_t r1;
        volatile uint32_t r2;
        volatile uint32_t r3;
        volatile uint32_t r12;
        volatile uint32_t lr; /* Link register. */
        volatile uint32_t pc; /* Program counter. */
        volatile uint32_t psr;/* Program status register. */
    
        char str[20];
    
        r0 = p_stack->r0;
        r1 = p_stack->r1;
        r2 = p_stack->r2;
        r3 = p_stack->r3;
    
        r12 = p_stack->r12;
        lr  = p_stack->lr;
        pc  = p_stack->pc;
        psr = p_stack->psr;
    
        sprintf(str, "r0:%x\n", r0);
        SEGGER_RTT_WriteString(0, str);
    
        sprintf(str, "r1:%x\n", r1);
        SEGGER_RTT_WriteString(0, str);
    
        sprintf(str, "r2:%x\n", r2);
        SEGGER_RTT_WriteString(0, str);
    
        sprintf(str, "r3:%x\n", r3);
        SEGGER_RTT_WriteString(0, str);
    
        sprintf(str, "r12:%x\n", r12);
        SEGGER_RTT_WriteString(0, str);
    
        sprintf(str, "lr:%x\n", lr);
        SEGGER_RTT_WriteString(0, str);
    
        sprintf(str, "pc:%x\n", pc);
        SEGGER_RTT_WriteString(0, str);
    
        sprintf(str, "psr:%x\n", psr);
        SEGGER_RTT_WriteString(0, str);
    
        //wait to allow the RTT transfer to complete
        nrf_delay_ms(2000);
    
        // Restart the system by default
        NVIC_SystemReset();
    }
    
  • Thanks, Darren and Bjørn,

    I finally got the debugger to work with "Debug without downloading". This function was disabled in the IDE previously. I'm not sure why it suddenly got enabled, but I suspect I have checked a "debug info enabled" somewhere.

    However, now I'm able to debug with the error present. I have also added the Hardfault_process and a lot of RTT log messages.

    It seems like the application is crashing in the Nordic SPI driver (nrf_drv_spi.c), when inside "spi_xfer()" function. It seems like it is chrashing after enabling interrupt for the callback function for the SPI. When I look at the registers for SPI(2), I can't see any problems. And after reflash, it works perfect. The application is only chrashing if started from bootloader.

    The hardfault handler is not hit, nor the app error handler, or reset vector.

    Is this something you have seen before?

  • Hi Jan, the bootloader does not perform a reset when it passes execution from itself to the application so any configuration of peripherals done in the bootloader will be retained through the branching operation. I see that you have modified the bootloader by removingthe button and LED handling in the bootloader. Do you see the same behavior with the standard bootloader? Which pins are you using for the SPI(2) interface?

Related