Other Parts Discussed in Thread: ENERGYTRACE
We developed a custom beacon using CC2640R2F that advertises a client ID and time of day every 500 ms. The beacon is mounted on the wall of a customer facility. Every 5 minutes an RTOS clock causes the processor to update the advertised time-of-day. The firmware is based on Simple Peripheral example code.
The CC2640R2F programs, starts, runs great at first. It advertises every 500 ms as desired using default parameters. At some point we connect to processor with a cell phone Bluetooth, set some parameters, and disconnect. These parameters contain a customer ID, time-of-day, and service ID that configures the advertising. Following disconnect the processor begins advertising with the new parameters as desired and is no longer connectable. This is part our commissioning process. All is good to this point.
A week or two later we discover the beacon has ceased to advertise. Examination reveals the batteries (2 AAA) are either dead or significantly drained. With an oscilloscope I have confirmed the 24MHz crystal is operating 100% duty cycle, whereas typically it shuts down between advertisements. I connected with JTAG and debugger and found the main processor is alive and well but is continuously bouncing around several power management functions in TI code. These appear to be idle activities. The 5 minute RTOS clock event never occurs.
As far as I can tell the RF Core appears to be hung. It is no longer generating events to the main processor. Checking TI support wiki I see a similar event has happened with other users. Sometimes it was attributed to an ESD event. In our case, the beacon is mounted on a wall in a housing and is not touched by anyone so ESD should not be an issue. However, the failure mode seems to be identical. Since RF transceiver is not sending events to the main processor the system stays in ACTIVE state and quickly drains the batteries.
I have had this problem with both YFV DSBGA part and 7x7mm RGZ VQFN part. We designed the part originally with RGZ part but switched to YFV part due to part shortages. The problem seems to be worse on YFV part.
Is this a known issue? Is there a work-around?
I have added a WDT timer to system that resets the board if the processor hangs. It uses a 500 ms RTOS timer to pet the WDT. If RTOS does not generate event every 500 ms the WDT will eventually expire and reset the board. This seems to have helped but it is a band-aid. I would like to know root cause.
