CC2640R2F-Q1: BLE LINK FAIL

Hi,

I'm not sure there is any relevant information to go off here to start so let's try to get some more information first.

Can you please more clearly define what exactly the problem is? You say there is a disconnect, but do you have a air sniffer trace?

What version of the SDK is being used? 

What role is the Bluetooth device?

What application is it in?

What target is the device connected to?

How is the issue reproduced?

What is a Bluetooth soft reset failure? I've never heard of this.

Please provide more specific information so we can assist. Thank you. 

1, No air sniffer trace is used. After the phone actively disconnects the cc2640, the cc2640 receives the GAP_LINK_TERMINATED_EVENT and then actively performs asoftware reset. at this time, cc2640 did not reset successfully;

2, version number:simplelink_cc2640r2_sdk_4_20_00_04__1;
3, peripheral role;
4, advertise, connect, communication.
5, mobile phone.
6, software reset in the GAP_LINK_TERMINATED_EVENT

Hi Wang,

When you say the device did not reset successfully, can you please elaborate more as to what you did end up seeing?

Did the user on the phone terminate the connection or was the disconnection driven by the mobile device automatically?

Maybe even more importantly, why exactly are you wishing to reset the device after receiving a link termination event? 

Please take an air sniffer trace. 

1, Under normal conditions, the boot will output A1 00/A2 00 after soft reset, as shown in the red marked part of the attached figure. When a fault occurs, execution goes to GAP_LINK_TERMINATED_EVENT and the serial output is 16 00. But there is no output A1 00/A2 00. So the hardware reset as shown in the picture.

2, The mobile phone user terminates the connection.

3, I want 2640 to stay in its initial state before every connection. 

4, ok, The red box marked 16 00 in the supplementary figure indicates that GAP_LINK_TERMINATED_EVENT has been received.

Hi there,
 If the device ends up in a fault, it will not necessarily reset, unless you specifically call the reset function from inside the fault/exception handler. Which would explain why you don't see the A1 00/ A2 00. If you want to be able to reset your chip after it encountering a fault, I would suggest using a watchdog timer. This would then cold reset the chip, allowing for the boot-up sequence to happen again.

Looking at the code snippet you sent, have you tried to run your code in debug session to see that the SysCtrlSystemReset(); actually gets called? It is possible that the chip ends up in a fault/ exception handler before actually getting to the SysCtrlSystemReset function, meaning that that function is never called, hence the reset doesn't occur. Please try to run your software through a debug session to see if this is the case.

To ensure that the SysCtrlSystemReset() function actually resets the device, you can try calling that API from a different context to see if the reset actually occurs.

Best,
Achyut Ray

A word of caution, if you are in a debug session, and then run the SysCtrlSystemReset() function, it will end up disconnecting the debugger, which will break the session. This is not an issue, it is expected behavior. To avoid this, you can set a breakpoint on the SysCtrlSystemReset() function, and see if that breakpoint is ever reached.

1, Sorry, when I say fault, I mean software reset failure,  It's not a hardware failure...

2, The failure probability of soft reset is very low, and it is difficult to debug.

Hi again,

Thanks for the clarification.

1. Have you tried running the code in a debug session? Additionally, were you able to set a breakpoint in the link_terminated_event case to see if the reset function ever gets called? I understand that it is tricky to reproduce the issue on your end, but I will be unable to provide any more insight, unless I know what is happening, and why.

2. Furthermore, have you tried using a watchdog timer to avoid the scenario where the code doesn't properly reset? 

Best,
Achyut Ray

1,  tried using a debug session, set a breakpoint in the event to call a soft reset function. Because the failure rate is low and debugging cannot continue after a soft reset, there is no way to know what happened to the failure.

2, The current project has running watchdog.

Hi there,
Can you check if you have the "Warm Reset converted to System Reset" enabled on your side? You can check this by looking at the PRCM register and then looking at the WARMRESET field. This is to ensure that the software reset actually resets the whole device and not just parts of it. You can read more about this in the Technical Reference Manual under section 6.7.1.3 and 6.7.2.
For ease of access, here is the link to the TRM: www.ti.com/.../swcu117i.pdf

Instead of using "Warm Reset to System Reset", a cold reset was used.

There are a few possibilities that I would need more clarity on:
- Does the Watchdog ever timeout?
- What is the state of the device when the software reset fails? Does the device still show signs of being active? You can check this by having LED's that are toggled periodically. If the device is in an unknown state, the LEDs won't toggle.
- When you say that the reset fails, I am unable to understand what about resetting doesn't work, can you please explain the behavior you are seeing?
- What is the periodicity of this issue? How reproducable is this?