Secure DFU bootloader problem nRF52832

RE: Secure DFU bootloader problem nRF52832

bjorn-spockeli — Tue, 31 Jan 2017 09:30:53 GMT

Hi Jan, glad to hear that you found the cause of the issue!

RE: Secure DFU bootloader problem nRF52832

janR — Tue, 31 Jan 2017 09:09:56 GMT

I finally got this to work. It turned out that it wasn't related to bootloader at all.

I use the FreeRTOS in my application. I have used "ble_app_hrs_freertos" example project as a starting point. It turned out that if I built the "ble_app_hrs_freertos" project and used the bootloader to flash, this application ran just fine.

When I looked after differences between "ble_app_hrs_freertos" and my application, it turned out that I had added some HW init between the softdevice BLE stack init and the while() loop in ble_stack_thread that handles events from softdevice. I guess it took too long time from BLE stack was initialised until events were handled, so the softdevice throwed an exeption. This exeption reset the processor. I guess I have to implement some code to handle this in a better way, as I didn't catch this.

After I moved the HW init to another thread, the application ran fine.

I'm not sure why the application didn't chrash when running without bootloader, but I suspect there is timing differences involved with and without bootloader.

Anyway, thanks for helping.

Regards, Jan

RE: Secure DFU bootloader problem nRF52832

bjorn-spockeli — Mon, 30 Jan 2017 13:48:44 GMT

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?

RE: Secure DFU bootloader problem nRF52832

janR — Thu, 19 Jan 2017 14:48:14 GMT

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?

RE: Secure DFU bootloader problem nRF52832

WestCoastDaz — Thu, 19 Jan 2017 03:52:28 GMT

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();
}

RE: Secure DFU bootloader problem nRF52832

bjorn-spockeli — Wed, 18 Jan 2017 09:56:39 GMT

It sounds like the device is Hardfaulting. Are you able to identify the last function that is called by the application before the reset occurs through the RTT log?

RE: Secure DFU bootloader problem nRF52832

janR — Mon, 16 Jan 2017 15:20:55 GMT

Buttonless_dfu service is initialized after peer_manager

RE: Secure DFU bootloader problem nRF52832

janR — Mon, 16 Jan 2017 15:18:49 GMT

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.

RE: Secure DFU bootloader problem nRF52832

janR — Mon, 16 Jan 2017 15:13:34 GMT

Hi Bjørn, I am using IAR Embedded Workbench IDE (7.80.3), and IAR ARM C/C++ compiler. I compile and link from the IDE using the .eww/.ewp files that comes with SDK

RE: Secure DFU bootloader problem nRF52832

bjorn-spockeli — Mon, 16 Jan 2017 13:02:39 GMT

Hi Jan, are you using armgcc and the makefile that comes with the SDK?

RE: Secure DFU bootloader problem nRF52832

Nguyen Hoan Hoang — Fri, 13 Jan 2017 18:02:57 GMT

Did you initialize buttonless_dfu service before or after peer_manager. if buttonless_dfu is initialized before peer_manager, it is likely be the cause of the crash. In fact anything that uses fds will have the same problem. It is due to the fact that fds initialization is async. In order to wait for the completion event, one has to do the event wait loop an this is done after everything is initialized. So it causes a problem when another fds initializes while the previous one has not finished. Both peer_manager & dfu use fds, hence cause of problem.

RE: Secure DFU bootloader problem nRF52832

WestCoastDaz — Fri, 13 Jan 2017 16:13:15 GMT

Jan,

Have you turned on the watchdog timer in the bootloader or have you checked if you application is hitting the hard fault interrupt?

Cheers, Darren