Application crash after disconnection

[julienh]

Hi,

I have an application with an accelerometer. This one communicate in I2C (TWI ). The accelerometer send a "data ready" signal every 20ms. I'm using the GPIOTE module to detect this signal and read the acceleration (I2C).

Each time I disconnect the Bluetooth, my application crash. I don't have any information to help me to debug on my app_error_handler. When this error happens, the execution stop at "Unknown funtion 0x000006B0".

1. I tried to disable data ready interuption on the accelerometer and the error disappear (seems to be related to a priority issue with GPIOTE / TWI and SoftDevice).
2. I thought that this issue was realated to a timing issue due to the GPIOTE interuption and TWI read during advertising start so I tried to disable GPIOTE on the data ready input when I have a disconnection event but that doesn't solve the problem.

I already saw another topic about that but the fix is not clear and I don't understand the root cause (devzone.nordicsemi.com/.../).

What I have understood from this topic is that I should use the ble_debug_assert_handler but I don't understand how to link this one with the app_error_handler. Do you have any example?

Any idea to help me to solve this issue? I'm on it since a while ...

Thanks

[Martin Tverdal]

at address 0x6B0 in the SoftDevice is code for handling HardFaults. Both HardFaults generated by the application and the SoftDevice will be handled first by code at this address.

So, the first question is, what generated the HardFault. That should be possible to see by examining the callstack to see what was running before the HardFault happened.

Second question is why the SoftDevice is not handling it as expected. If it was a application hardfault, it should of forwarded it to the application.

When this happens, and you are debugging, could you tell me the value of address 0x20000000, ie the first word in ram? And also could you tell me the value at address 0x1B00C (should be the applications HardFault handler)?

Are you using a bootloader?

[julienh]

Thanks to my functional needs, I don't need the accelerometer when the device is connected in Bluetooth. I implemented a sequence to disable the data_ready interruption and GPIOTE and now it seems to work fine. I'm a little bit frustrated to not understand what's happened but I have to deliver this code ASAP so I will not try to go back to see what is happening.

By "chance" (not sure that this is the word), I talked with a colleague which had the same behavior (same SDK and SD) but in a totally different project (nothing related with my project and product). I asked him to check the 2 registers that you asked for. He had : 0x1B00C -> C3 B0 01 0x20000000 -> 00 10 00 00 00 B0 01 00 01 00 08 00 87 00 59 00 03 00 05 00 07

[Martin Tverdal]

It's very frustrating to not understand whats going on indeed. Those addresses looks good to me.

If you want to take more time to debug this, a very good next step would be to see what is causing the HardFault by examining the call-stack. To do that, the best thing would be to set a break point at that address (0x6B0). Lets say SP is 0x2000400C when you hit the breakpoint. The interesting values to know (post them here, or examine yourself) would be 20003FFF0 - 0x2000400C.

If you see here: infocenter.arm.com/.../index.jsp Whatever is located at address 0x20004004 (PC), will be the address that caused the HardFault. If that is inside the SoftDeivce ie < 0x1B000. It was the SoftDevice that caused the HardFault. If it is > 0x1B000, the HardFault is caused by the application.

Let me know if you try this, and what the result is.