Hard fault from nrf_log_frontend_dequeue()

Hi,

I'm getting a hard fault that I really need some help to debug. My call stack is shown below and includes nrf_log_frontend_dequeue() as well as a custom service function which calls sd_ble_gatts_hvx().

I checked the CFSR upon the fault following this guide and the only error flag set is for the following:

"IACCVIOL - Indicates that an attempt to execute an instruction triggered an MPU or Execute Never (XN) fault."

This error occurs in two cases:

(1) immediately upon connection with the peripheral device if--and this is a sort of strange condition--if SAADC acquisition time is set to 1us or 5us (NRF_SAADC_ACQTIME_1US)

(2) rarely/sporadically if SAADC acquisition time is set to anything >5us

One connection is that my custom function ble_sws_meas_send is called by the SAADC callback. But the frequency of SAADC reads is set independently of acquisition time, so I don't know why this would have an effect.

Thanks in advance!

Parents

0 user103731 over 4 years ago

Here is the output on the debug terminal after enabling the HardFault handling library:

<info> app: 141, 29979, 29984 [This is an application message indicating completion of 100 ADC measurements]
<info> app: Connected. [This is an application message indicating connection to the central device]
<info> app: 142, 29981, 29985 [This is an application message indicating completion of 100 ADC measurements]
<error> hardfault: HARD FAULT at 0x0C010107
<error> hardfault: R0: 0x00000000 R1: 0x00000000 R2: 0xE000E100 R3: 0x00000000
<error> hardfault: R12: 0x200044D2 LR: 0xDC008E01 PSR: 0x0000051E
<error> hardfault: Cause: The processor has attempted an illegal load of EXC_RETURN to the PC, as a result of an invalid context, or an invalid EXC_RETURN value.
<error> app: Fatal error

The ble_sws_meas_send function first encodes the measurement into a buffer for the BLE data packet, and then queues the packet for transmission with sd_ble_gatts_hvx(p_sws->conn_handle, &hvx_params), which is where the error seems to occur, according to the call stack.

The SAADC sample rate is 2 kHz. It is scanning, and effectively oversampling, two channels. The buffer is the size of two readings x2 (for double-buffering). The SAADC callback is accordingly executed every 2 kHz, and then after every 100 measurements (for oversampling) the ble_sws_meas_send function is called to transmit an oversampled reading.

The hardfault does not occur without BLE connection - before connecting the central device, the ADC measurements run fine with no faults.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 user65515 over 4 years ago in reply to user103731

There is a known bug in nrf_log_frontend_dequeue() which may or may not be an issue in this case; here is a link to the discussion:

bool nrf_log_frontend_dequeue(void)
{
    if (buffer_is_empty())
    {
        return false;
    }
    // Note also add atomic flag set before this __DSB() and after this function exits
    // See https://devzone.nordicsemi.com/f/nordic-q-a/39188/nrf_log_frontend_dequeue-must-be-atomically-protected-against-re-entry-from-interrupt-context
    if (nrf_atomic_flag_set_fetch(&m_log_data.log_is_busy))
    {
        return false;
    }
...

nrf_log_frontend_dequeue-must-be-atomically-protected-against-re-entry-from-interrupt-context

Reply

0 user65515 over 4 years ago in reply to user103731

There is a known bug in nrf_log_frontend_dequeue() which may or may not be an issue in this case; here is a link to the discussion:

bool nrf_log_frontend_dequeue(void)
{
    if (buffer_is_empty())
    {
        return false;
    }
    // Note also add atomic flag set before this __DSB() and after this function exits
    // See https://devzone.nordicsemi.com/f/nordic-q-a/39188/nrf_log_frontend_dequeue-must-be-atomically-protected-against-re-entry-from-interrupt-context
    if (nrf_atomic_flag_set_fetch(&m_log_data.log_is_busy))
    {
        return false;
    }
...

nrf_log_frontend_dequeue-must-be-atomically-protected-against-re-entry-from-interrupt-context

Children

No Data