app_error_fault_handler() called with id = NRF_FAULT_ID_SD_ASSERT and PC = 0x18434

[jhwang1]

I'm debugging an issue which triggers app_error_fault_handler() and it indicates id=NRF_FAULT_ID_SD_ASSERT, PC=0x18434, and info=0.

This address falls in SD, and how can I find the cause of this fault ?

I use SDK 15.2.0 with (SoftDevice S140 v6.1.1)

[Amanda Hsieh]

Hi Jung,

Please see this post.  

Are you using timeslots, and/or disabling interrupts from the application?

-Amanda H.

[jhwang1]

I was experimentally adding more BLE roles to an existing BLE peripheral product, and this problem happened during overnight tests. No disabling interrupt or timeslots are used.

Could this happen when too many BLE functions are enabled such as multiple connections, or starting both BLE scan and advertise at the same time while an active connection is established? 

[Amanda Hsieh]

Hi Jung,

Not sure what caused the problem. 

It seems like you got "id" also along with "PC". Since you narrowed the hardfault id to be NRF_FAULT_ID_SD_ASSERT. The line number and file name of the assert is located inside the info structure in app_error.h file

typedef struct
{
    uint16_t        line_num;    /**< The line number where the error occurred. */
    uint8_t const * p_file_name; /**< The file in which the error occurred. */
} assert_info_t;

Check if you have some valid structure here, if not then something is wrong. Are you seeing these values in a log or in a debug window? If it is the debug window, then i would suggest you to compile the code with no optimizations (and hope that the timing has not changed to be able to reproduce this error.) If you use segger, you can compile with debug mode. 

-Amanda H.

[jhwang1]

Amanda,

PC I got is 0x18434, and this address is part of Soft Device. Therefore, I do not have way to change the compiler optimization for it. Can you check your Soft Device code and let me know in which case the assert at 0x18434 is triggered?

[Amanda Hsieh]

Hi Jung,

This looks to be a bug/race condition in our SoftDevice related to connecting, but we do not have enough information to solve this. Is it possible to reproduce this bug consistently? Do you have a procedure to do it in the way we can reproduce on nRF52840DK? Would you like to share the project only with us (I can set this case to private mode)? If you have sniffer logs that show us the traffic with the device it may also be useful.

-Amanda H.