i have some bare-metal RF code that runs on my nRF52-DK, which i'm currently porting to my nRF54-DK.... functionally, everthing is working just fine -- the boards can in fact talk to one another....
in both designs, i explicitly start/stop the external 32MHz crystal using the CLOCK peripheral.... since i'm often starting the HFXO after awakening from a low-power sleep, i'll need to wait for the crystal to become ready (actrually TUNED on the nRF54).... since this can require ~200-300us, i'll await a CLOCK interrupt once i've performed the START task.... needless to say, this WFI puts the MCU into a "light-sleep" where the HFCLK keeps running....
again, all is well on the nRF52.... one the nRF54, however, i'm seeing very erratic behavior.... in a stand-alone test where i simply start/wait, i've seen my program spontaneously reset due to a CPU lockup.... i've also take illegal memory access faults.... putting various delays in my test program simply "moves the problem around".... and sometimes (on a cold morning), it actually works....
putting this in a larger context, when i attempt to repeatedly transmit a packet (say at 4Hz), i'll fail in this manner after some initial set of (1-5) packets successfully go over the air....
in general, my test (which works just fine on the nRF52) will repeatedly start-wait-stop the external crystal....
is there some specific to the nRF54 that i might be overlooking??? i've tried various combinations of explicitly using the START and XOTUNE tasks; i've also tried using PLLSTART/PLLSTOP around "short" WFI sequences....
finally, i'm also not 100% convinced that i'm fully disabling the HFXO (and by extension the HFCLK/PLL) when i enter "deep-sleep".... unlike the nRF52, i'm still measuring 400uA of current when in deep-sleep.... is there some other subtle difference between the nRF52 and nRF54 that i might be missing as well???
