nRF52832 NRF_FAULT_ID_SD_ASSERT @PC 0x00014ce0

[hiyyq]

This is a product based on nRF52832, which uses BLE Bluetooth to scan iBeacons and communicates with an LTE module via UART for data reporting.

It occasionally enters the app_error_fault_handler with a high probability, where the ID is 1 (NRF_FAULT_ID_SD_ASSERT), the PC is at 0x00014ce0, and the info is 0.

After automatically executing NVIC_SystemReset, it enters this state again within a short period, such as 5 seconds to 1 minute, repeating more than ten times.

I wonder what assertion the SoftDevice has made at this PC address. 

Environment information:

nRF52832

s132_nrf52_7.2.0_softdevice.hex

nRF5_SDK_17.0.2_d674dde

running without RTOS

ble_gap_scan_params_t scan_param = {
.active = 0x0,
.interval = 40,
.window = 32,
.filter_policy = BLE_GAP_SCAN_FP_ACCEPT_ALL,
.timeout = 0,
.scan_phys = BLE_GAP_PHY_1MBPS,
};

Could you help me analyze the possible causes of this issue? Thanks a lot

[Turbo J]

There is a reason why this SDK is no longer recommended for new designs. Switch to NCS ASAP.

Typical reason for the SD Asserts is that you forgot to properly set the interrupt priority for one of the peripherials. Its one of the restrictions when using softdevice.

[hiyyq]

I searched all my code with the keyword "_OBSERVER" and found that I only used one NRF_SDH_BLE_OBSERVER to handle Bluetooth scanning events. For chip peripherals, I only used UART, SAADC, and RTC.

The priority of the only NRF_SDH_BLE_OBSERVER is 3, In the event handling of NRF_SDH_BLE_OBSERVER, only data from BLE_GAP_EVT_ADV_REPORT is stored in the buffer array, with no other operations performed. All priorities use the default configuration of the SDK. 

[Hieu]

Hello hiyyq,

For the priority, the reserved levels are 0, 1, and 4. See Interrupt priority levels.

I don't know which SoftDevice you are using, so it's not possible to tell what that assert mean. I think we should first look at some more obvious spots anyway.

Does your application do anything else with BLE other than scanning?

If not, that narrows the issue down to either starting scanning, stopping scanning, or handling scan reports.

From your description, I suspect you might be sending scan report via UART directly in the SoftDevice event callback. Is that the case?

If so, please stop doing that, and instead only queue the data and send later. It's best the queueing setup also have some duplicates and overflow handling, since scan reports can come very rapidly.

If a safe handling is already done, then please try to determine after which operation the assert happens, then we review the context of the problem.

Hieu

[hiyyq]

Glad to hear from you. I‘m using the nRF5_SDK_17.0.2_d674dde and s132_nrf52_7.2.0_softdevice

[hiyyq]

I'm not sure about the conditions under which the assertion occurs; it always catches me by surprise. The day before yesterday, I tried changing the NRF_SDH_BLE_OBSERVER_PRIO_LEVELS from 4 to 8 and the priority of NRF_SDH_BLE_OBSERVER from 3 to 5. Fortunately, the probability of the assertion seems to have decreased significantly. So far, only 1 occurrence has been observed in 2 devices. I don't perform UART transmission operations within the scan processing event. Instead, I only carry out simple filtering judgments and then store the data in an array buffer for transmission in the subsequent main while loop.

[Hieu]

Did you already setup the scan to be without a timeout?

If so, considering the fact that the changes to priority of SD BLE observers helped, it is most likely the problem is in handling of the callbacks.

A test to confirm this would be commenting out all scan report processing. If you want to keep the rest of the system the same, you could add a very simple counter to increment when scan reports come. The rest of the logic act upon this counter instead.

If the test confirms, please try to offload all handlings outside of the scan report processing.