We have an existing fielded design which has been working well; the units are running a CC1350 with the BLE stack (built with sdk version 2.30.0.20) but we have observed when testing some units that have been placed in long term storage (6+ months idle) that around 10% of the units experienced a reset while in storage.
Our firmware does not enable the internal watchdog because the energy demands would exceed our idle threshold, and we do not employ any form of external watchdog nor do we have code in place which would invoke a software reset. The reset pin is pulled up to VDD through a 10k ohm resistor. These units are powered via a CR2032 battery with 300uF of ceramic capacitance placed close to the CC1350 to lower the effective IR of the battery during pulsed loads.
In the idle regime these units are operating in they are simply waking up using a TI-RTOS clock callback every 2 seconds to check the state of a hall effect sensor connected to a GPIO. This HES controls the BLE advertisements, and in storage the units are in a fixed configuration where the HES is always active and no advertising will occur.
We're at a loss for explaining what may be behind these resets and instrumentation of the system to observe them in-situ has proved problematic since they seem to happen over a period of months.
I didn't see anything in the errata for the MCU or the subsequent SDK revisions that suggested there was a convenient explanation for this behavior, but I would appreciate anyone with expertise in this system making sure this doesn't sound like an understood failure mode in the RTOS or MCU.
