This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2F: BLE5 stack hangs randomly

Part Number: CC2640R2F


Hi,

I am developing my custom application from the simple_peripheral included in the simple link SDK 4.30. My device communicates with an Android App. The issue I am facing is that my device is getting disconnected from the App randomly and when that happens only a hard reset can bring the device to an active state. We have a button for restarting advertisement but that doesn't work when this issue happens. But the same button is used for the hard reset and is working even after the issue happens. So it seems to be some issue happening in the BLE5 stack side. The issue is happening very rarely once in two days and we cannot figure out how it happens. Can anyone advise me on how to debug this issue and solve it?

Waiting for a reply 

  • Hey Anjaly,

    I would start by reading through our Debugger's guide here. In particular, I'd first try to rule out any memory corruption issues by monitoring the HEAP metrics.

    Depending on the depth of this issue, it may be helpful to have a sniffer capture to view the traffic over the air when the issue happens.

    For now, I would work to rule out any memory issue.

    EDIT: I would also recommend trying to reproduce the issue while using simple_central or host_test as your central device (to rule out any potential issues with the App). You can also try using another phone if available to see if the issue is related to this specific phone/OS version.

  • Hi Ammar,

    Thank you for your reply. I will rry out your suggestions and get back to you.

  • Hi Ammar,

    I was trying to reproduce the device freeze issue. I found like it is happening when I am disconnecting the device from the mobile App. When I tried to debug it, I foound like the device is not receiving any Stack messge at that time. Can you suggest me a method to debug this kind of scenario to really find out at what pointit hangs?

    Waiting for a reply

  • Hey Anjaly,

    When the device is connected to the debugger, do you hit a HAL assert? If so, what is the cause?

    Have you ruled out a memory issue by enabling HEAPMGR_METRICS ?

     We have a button for restarting advertisement but that doesn't work when this issue happens. But the same button is used for the hard reset and is working even after the issue happens.

    I do not understand the above statement. Can you clarify how this works?

  • Hi Ammar,

    I debugged the issue and found like it a Stack overflow. But I could not pin point at what line of the code got the stacj overflow. Also, I am getting this when the device got disconnected from App. Can you suggest any methods to root cause the issue?

  • Hi Ammar,

    I am attaching some screenshot of my debug window. Can you check this and let me know your comments. It seems to be an "Oveclocked chip" error. How can I solve this issue.

  • Hi Anjaly,

    Sorry for the delay. Since the IMPRECISERR busfault is reported, you should try manually disabling buffered writes.

    The below excerpt is taken from the Debugger's guide linked above:

    "

    If the exception is IMPRECISERR, PRECISERR can be forced by manually disabling buffered writes. Set CPU_SCS:ACTRL:DISDEFWBUF to 1, by either manually setting the bit in the register view in the debugger or by including <hw_cpu_scs.h> from Driverlib and calling the following.

    #include <ti/devices/cc26x0r2/inc/hw_cpu_scs.h>
    //..
    int main()
    {
        // Disable write-buffering. Note that this negatively affect performance.
        HWREG(CPU_SCS_BASE + CPU_SCS_O_ACTLR) = CPU_SCS_ACTLR_DISDEFWBUF;
        // ..
    }


    "
    Try this so we find out which memory address was written to when the exception was raised. This will give us an idea of a next step and see if your application is writing to this address or it's if it's used by the stack and we can go from there.