S130 softdevice hard fault

[Ian]

Hi

    I’m using NRF51822_XXAC + s130_nrf51_2.0.0_softdevice, my program work well most of the time, but it dies at 0x000006b0 sometimes.  Since I used the S130 softdevice, the chip's 0~0x1b000 space is the content of S130. Since the S130 has only one hex and no source code, I do not know what the address 0x6B0 is, but can only guess the handler of hardfault.

   Fortunately, this happened once when I was debugging my program. I checked the value of SP in the register window and get the current stack pointer, and then checked the contents of the stack in the memory window. According to the push mechanism of cortex-m0, the contents of R0~R3, R12, LR, PC, and XPSR should be stored in the stack in turn. I can see that the contents of the stack and the value of the corresponding register also correspond to one to one. At the same time as i found: LR = 0x000104D7, PC = 0x000104FC, both address is between 0 ~ 0 x1b000 is S130 internal address, so i think this is S130's internal code cause hardfault. It seems to be understandable as official S130 bugs, below this kind of situation, as a chip and S130 users, is completely unable to analysis and solve problems.

    The attached picture is the interface I caught during debugging. The content of register window,memory window and call stack window can verify the description and analysis I just did.

    Does anybody have any opinion on that? It's better to have the Nordic staff check this out.

    

[Vidar Berg]

Hi,

Looks like the CPU is halted inside the hardfault handler located in the Master boot record ( MBR - basically an interrupt forwarder) while it should have been forwarded  to softdevice --> application.  It is possible that SES has enabled "vector catch" and that is why the CPU gets halted in the MBR and not in the application/softdevice. While you are debugging, click on Debug in the menu bar and select Breakpoints -> Breakpoints and make sure to disable the breakpoint for the Hardfault exception.

Breakpoint view for Cortex M4

  

Also, do you have this function to catch softdevice assertions in your project?

/**@brief Callback function for asserts in the SoftDevice.
 *
 * @details This function will be called in case of an assert in the SoftDevice.
 *
 * @warning This handler is an example only and does not fit a final product. You need to analyze
 *          how your product is supposed to react in case of Assert.
 * @warning On assert from the SoftDevice, the system can only recover on reset.
 *
 * @param[in] line_num   Line number of the failing ASSERT call.
 * @param[in] file_name  File name of the failing ASSERT call.
 */
void assert_nrf_callback(uint16_t line_num, const uint8_t * p_file_name)
{
    app_error_handler(DEAD_BEEF, line_num, p_file_name);
}

 

[Ian]

Do you mean the application occur hard fault, but is it halt here because of a breakpoint?

[Vidar Berg]

Either that, or in the softdevice. The processor should not be halted in the MBR region unless you have the breakpoint enabled. Have you tried to disable it?