Other Parts Discussed in Thread: SEGGER
I have a CC1310 with an AMS3933 125 kHz receiver (same as https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/980542/cc1310-125khz-switching-noise-from-dc-dc-buck?tisearch=e2e-sitesearch&keymatch=CC1310%20125%20noise#).
On start-up, we cause the antenna coils to resonate so we can measure their frequency and trim them to precisely 125 kHz. After the coil starts resonating we sleep for 10ms with a `usleep(10000)` before we measure their resonant frequency. We are starting to see boards which never exit this call to usleep. Most of our boards are fine. Some of our boards worked originally, but then stopped working - always inside the call to usleep with the coil resonating.
We have a GPIO line we can pull which causes the UART to be enabled on boot-up. We don't do this in production as the power consumption is too high, however if we do pull this line to enable the UART, the non-working boards work fine when they are booted up (with exactly the same firmware - they have not been reflashed).
Similarly, if we turn on the JTAG logic by plugging in an XDS110 or a SEGGER J-Link, connecting with GDB and resetting the boards, the non-working boards work fine.
If we turn remove the debugger, and set the GPIO so the UART is disabled, then power cycle it crashes inside the usleep again - every time. We have a watchdog enabled, but it never fires!
I can work around the issue by not calling usleep whilst the 125 kHz coil is resonating - a busy-wait (a for-loop counting to ~43,000) works fine. Calling usleep elsewhere in our code (after tuning is complete, and so when the coils are not resonating) works perfectly - we do it all the time when we power the EEPROM on, and when we operate the status indicators.
I'm now concerned whether the CC1310 is susceptible to 125 kHz noise when in low power sleep modes, as the system spends most of its time in deep sleep and may often be in the presence of appliances which produce lots of EMI, as well as 125 kHz transmitters.
For reference, we're using CCS10, simplelink_cc13x0_sdk_4_10_02_04 in NoRTOS mode, and GCC gcc-arm-none-eabi-7-2017-q4-major.
