Data Bus Hard fault when handling secure connection bonding

[thin_ice]

Hello,
I am working on an application which is freeRTOS based, now I wanted to integrate Glucose sensor app which supports secure connection and bonding. In 

ble_evt_handler, if I take out pm_handler_secure_on_connection(p_ble_evt); then my code still works it's just doesn't bond properly. However, if I leave this line of code in, I got hard fault instantly as soon as the bonding process is initiated. Could you help pointing me to the right direction to troubleshoot this issue ?

I have a feeling it has to do with  freeRTOS but I am not so sure.

Uart output:

<error> hardfault: HARD FAULT at 0x0002C8FC

<error> hardfault: R0: 0x00000000 R1: 0x4605FE50 R2: 0x20009208 R3: 0x20009208

<error> hardfault: R12: 0x200089C0 LR: 0x0002C8F1 PSR: 0x8100000E

<error> hardfault: Cause: Data bus error (PC value stacked for the exception return points to the instruction that caused the fault).

<error> hardfault: Bus Fault Address: 0x4605FE50

Call stack:

void HardFault_c_Handler()   @ 0x00029F58

void PendSV_Handler()         @ 0x0002C8EC

void PendSV_Handler()         @ 0x0002C8EC

Thank you !

[Susheel Nuguru]

Hi,

Which SDK are you using?

There are two parts of investigation 

1) Try to find out if you have applied this patch to softdevice_task as it might cause some deadlocks and wrong states in the statemachine of peer manager

2) The Hardfault address 0x2C8FC is inside the application code. The below line should be able to reveal the instruction that is causing the hardfault. We can take a closer look after understanding what that is.

addr2line -e <src.elf> 0x0002C8FC

[thin_ice]

Hello, I am using SDK 15.2 and the address points to this line (xPortPendSVHandler) as you requested.

nRF5_SDK_15.2.0_9412b96/external/freertos/portable/GCC/nrf52/port.c:104

I am going to try the patch and let you know if it helps

[thin_ice]

so I found out that in sdk_config.h if I have #define PM_HANDLER_SEC_DELAY_MS 400 then immediately after connection is initiated I get a hard fault, but if I change it to #define PM_HANDLER_SEC_DELAY_MS 0 then I don't. This is already with the sdh_freertos.c patch you mentioned so I don't think the patch did anything.

Now with the interrupt priority mod, I still have the same problem. In my application, I stripped everything hardware out, what remains is just BLE stack and a couple of tasks. One of the task has nrf_ble_lesc_request_handler(), one is the "Logger" task.

[thin_ice]

so I confirmed that cause was I put nrf_ble_lesc_request_handler() in a freeRTOS task. This is because in the barebone example I saw they put it in the main loop so I had a task and stick it in. How do I explain the hard fault and how can I fix ?

[Susheel Nuguru]

Sorry for very late reply. Most likely you figured this out by yourself. 

the idea is to keep the logic into similar context. I do not still like the hardfault  being triggered, can you get the instruction address of the memory that caused the hardfault?

if you have already solved this, can you please update this thread so that others could get help from your experience.

[thin_ice]

Did you mean the instruction address that I provided earlier ? Please see my previous responses

[Andreas48752]

Hello! 

I think I may have the same problem here when using freeRTOS and calling nrf_ble_lesc_request_handler() in a task. But how to fix this? What was your solution? Thanks!