This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Application crash after disconnection

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

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related