Hardfault after BLE connection, in BLE with ADC app

RE: Hardfault after BLE connection, in BLE with ADC app

Jørgen Holmefjord — Wed, 04 Apr 2018 09:32:40 GMT

ble_nus_string_send will return NRF_ERROR_INVALID_PARAM if parameter p_length is greater than BLE_NUS_MAX_DATA_LEN, or if an invalid parameter is passed to sd_ble_gatts_hvx. Please check which length you are passing to the function.

RE: Hardfault after BLE connection, in BLE with ADC app

Alaa — Sun, 01 Apr 2018 11:16:35 GMT

As I said, it gave NRF_ERROR_INVALID_PARAM, and not TX buffer full

RE: Hardfault after BLE connection, in BLE with ADC app

Turbo J — Sun, 01 Apr 2018 11:09:34 GMT

The ble_nus_string_send() function can give you a "TX buffer full" return code for example, which you should handle somehow. Usually that means redesigning some stuff using FIFOs.

RE: Hardfault after BLE connection, in BLE with ADC app

Alaa — Sun, 01 Apr 2018 10:33:11 GMT

This was happening in the function saadc_callback() after executing the following:

err_code = ble_nus_string_send(&m_nus, value, bytes_to_send);

Which tries to send data via BLE. Currently I'm sending data in another function outside of saadc_callback() and it's working.

But you're right; the root cause of the problem should be fixed. I'm not sure where this is coming from though so I think I'll wait for responses...

RE: Hardfault after BLE connection, in BLE with ADC app

Turbo J — Sun, 01 Apr 2018 10:28:37 GMT

You should rather fix the call that generated the error code...

RE: Hardfault after BLE connection, in BLE with ADC app

Alaa — Sun, 01 Apr 2018 10:26:47 GMT

Good point!
It was coming from

APP_ERROR_CHECK(err_code);

err_code was equal NRF_ERROR_INVALID_PARAM

I'm not sure how this is causing hard fault but disabling this error check solved the problem.

Thanks

RE: Hardfault after BLE connection, in BLE with ADC app

Turbo J — Sun, 01 Apr 2018 10:10:25 GMT

Why dont't you just look at the call stack (gdb: "bt" command)?