CC2540: Connection locks up on any discovery

Apparently my images did not attach correctly. Here they are:

Hi Mack,

As you mention, it looks like the CC2540 is getting stuck in some sort of spin lock or exception - in a debugger, where you do end up when you pause execution?

As for what's causing this... I'm not sure, it looks like the slave literally stops showing up to events. (Does it ever readvertise?)

Regards,
Rebel

So, this is not a typical occurrence in our code baseline. Out of thousands of units, only a handful have done this. Upon resetting the device, the services return and everything is back to normal. We have seen other things that I think may be the same thing. We have seen some devices that only have some of their normal services listed, and We have some devices that will send out 100's of services that aren't actually there. If I had to guess, all of these things are related and could be from pointer corruption of a linked list of services. Are the services stored in some sort of linked list? I can try to get a the debugger attached, but there is no guarantee that it will occur again if the device resets as it is a small percentage error with large impact.

We now have another issue that I believe to be related pop up. We had a device that started with our regular advertising interval, then after some time and/or event, we are unsure, it was broadcasting at once every 5 minutes. Upon a reset it returned to normal operation just like the instances above. This leads me to believe that something is going on internal to the GAP/GATT. Maybe a memory issue? We have looked at our stack and heap usage extensively and have never got above 75% on either of them, so this is hard for me to believe. Any thoughts on what may cause that GAP/GATT to "mysteriously" change like this?

I am going to add a little more in hopes that someone may have an idea on what is going on. So, presently this is affecting about 1% of our devices. The GAP and GATT seem to be the things that are affected. Everything from devices that aren't advertising, to missing GATT characteristics, to Characteristic properties changing. The only thing in common that I can find with all the parameters that are being corrupted is that they are all static variables. Once this happens a reset fixes the problem as it is in RAM. We can't find anything else in common with this small number of devices. Any thoughts or ideas would be greatly appreciated?

If we can't figure out why, we can live with either detecting the GATT or GAP corruption and fixing it or just re-initializing the GAP and GATT periodically so that we may be able to communicate to the device eventually. Is there an elegant way to do either of these?

Hi Mack,

There's not much we can do here without being able to reproduce this issue, unfortunately.

If the HEAP manager is reporting everything is alright and none of the stacks are getting blown, then I'm not sure what could be causing this issue. Static variables getting corrupted definintely sounds like some sort of Runtime memory issue.

Regarding workarounds - when the issue does occur, is it possible for you to place a check-in for the return status of GAP_MakeDiscoverable?

If it's bad, you may be able to do a system reset - my assumption here is that when you get into this issue state, that the stack has already moved into the advertisement state.

The alternative could be periodically checking the GATT server via gattservapp_util.c functions and comparing them against constants? (not a great solution, but it's something) If they changed, then you know you've encountered this RAM issue and then reset.

Regards,
Rebel