Application crash after disconnection

RE: Application crash after disconnection

Martin Tverdal — Thu, 28 Sep 2017 09:19:30 GMT

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.

RE: Application crash after disconnection

julienh — Wed, 27 Sep 2017 21:08:46 GMT

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

RE: Application crash after disconnection

Martin Tverdal — Tue, 26 Sep 2017 14:38:56 GMT

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?

RE: Application crash after disconnection

julienh — Tue, 26 Sep 2017 10:30:32 GMT

Yes I'm using S130 V2.0.1 which is in the SDK bundle (12.3).
I'm getting the message in debugger mode from Segger Embedded studio. When I disconnect the bluetooth, the execution is stopped with select active call frame "unknown function at 0x000006B0". In the call stack, the last called address is 0x000006B0. I tried a lot of things since yersterday but nothing to do... Still the same issue when I disconnect (and start again the advertising). If I don't start the advertising again, no problem.

Is that helpful if I create a case with my code?

GPIOTE is in low accuracy. TWI IRQ priority low.

RE: Application crash after disconnection

MartinBL — Tue, 26 Sep 2017 10:05:01 GMT

Are you using S130 v2.0.1 that is bundled with SDK 12.3?
Are you getting the "Unknown funtion 0x000006B0" message from a debugger?

RE: Application crash after disconnection

julienh — Mon, 25 Sep 2017 12:24:05 GMT

What is "Unknown funtion 0x000006B0" and how is that possible to end in this unknown function? Do you have any example to use the ble_debug_assert_handler as explained on the previous topic?

RE: Application crash after disconnection

julienh — Mon, 25 Sep 2017 12:22:34 GMT

Nothing directly related to the disconnection event but an interruption on the GPIOTE can occur (accelerometer data ready signal) every 20ms. The gpiote interruption handler is really short (just changing a "data_ready" flag to true). Then I'm checking data_ready in the main loop and read the accelerometer value if a new data is available (I2C). Due to the unsynchronized interruption, I tried to disable this when I have the BLE_GAP_EVT_DISCONNECTED event but that doesn't solve the problem.
This is what I thought but in fact the TWI is already configured to low level as follow in the sdk_config.c

TWI_DEFAULT_CONFIG_IRQ_PRIORITY 3

I don't call any SD function from my TWI module neither from a GPIOTE interruption handler or something like that.

DEBUG is defined and I'm actually in debugging level 2 and optimization level 1. I tried before other without success. Will try again.

RE: Application crash after disconnection

MartinBL — Mon, 25 Sep 2017 08:50:35 GMT

Do you do anything special when you disconnect? Like reading from your sensor or print something to a serial terminal?
Could it be an issue with interrupt priorities?
Are you debugging with optimization level -O0 and DEBUG defined?