nRF52: I2S causes 600uA extra power usage if bluetooth is off

[gfwilliams]

This looks like a nRF52 hardware 'anomaly'. Doing something like this works fine:

NRF.setConnectionInterval(100); // set lower power connection. -> 60uA
// write some neopixel data - we're still using ~60uA on average
setInterval(function() {
  require("neopixel").write(Q3.sda, [0,1,2,3,4,5]);
}, 5000);

But now if you do NRF.sleep() then the next time the neopixel.write function is called, power usage jumps from 60uA to 600uA and stays there.

Tested on Jolt.js - but it seems like it's an issue on nRF52832 as well.

The following change actually fixes this:

--- a/targets/nrf5x/i2s_ws2812b_drive.c
+++ b/targets/nrf5x/i2s_ws2812b_drive.c
@@ -164,8 +164,12 @@ ret_code_t i2s_ws2812b_drive_xfer(rgb_led_t *led_array, uint16_t num_leds, uint8
        // as far in advance as it can.
        while (i2s_ws2812b_drive_flag_buffer_cnt < 5);
 
-    // finally, stop the output
-    nrf_drv_i2s_stop();
+       // finally, stop the output
+       nrf_drv_i2s_stop();
+
+       // USE_WORKAROUND_FOR_I2S_STOP_ANOMALY (anomaly 194) from SDK17 (SDK15 doesn't have this included)
+       *((volatile uint32_t *)(((uint32_t)NRF_I2S) + 0x38)) = 1;
+       *((volatile uint32_t *)(((uint32_t)NRF_I2S) + 0x3C)) = 1;
 
        // un-initialize i2s
        nrf_drv_i2s_uninit();

which was copied from SDK17. However after a while it causes some kind of system lockup and the chip halts, drawing 9mA - so this needs further investigation

[d3nd3]

I asked my ai agent to help fix this issue, and I provide some of its hints. Let me know if you don't appreciate this type of contribution, I thought it might help you.

Ai Response start
Cause
Wrong order for FTPAN-194
Nordic’s nrfx flow is: TASK_STOP → write I2S+0x38 / I2S+0x3C → later disable the peripheral when STOPPED is handled.
Your experiment did the writes after nrf_drv_i2s_stop(), which already calls nrf_i2s_disable(). Touching those registers on a disabled block is a bad idea and matches “works for power, then weird failures”.

Double stop() and hang
i2s_ws2812b_drive_xfer() calls nrf_drv_i2s_stop() and then nrf_drv_i2s_uninit(), and uninit calls stop() again.
After the first stop, I2S is off. A second TASK_STOP + busy-wait on EVENTS_STOPPED can never complete → busy loop, ~9 mA, looks like a lockup.
Adding a wait-for-STOPPED step without fixing the double stop would make that hang easy to hit.

Fix (branch fix/i2s-ws2812-after-sleep-power)
All logic is in targetlibs/nrf5x_12/components/drivers_nrf/i2s/nrf_drv_i2s.c:

nrf_drv_i2s_stop() only runs the full teardown when state == NRF_DRV_STATE_POWERED_ON
So the second call from uninit() is a no-op.

Full stop sequence

Disable TX/RX pointer interrupts (unchanged, FTPAN-55)
Clear EVENTS_STOPPED, TASK_STOP
On nRF52832 / nRF52840, FTPAN-194 writes to +0x38 and +0x3C before disable
Poll EVENTS_STOPPED (with a timeout)
nrf_i2s_disable()
This matches Nordic’s ordering (same as current nrfx nrfx_i2s_stop for errata 194), but stays synchronous so the neopixel path doesn’t need the new IRQ-based driver.

Please re-test on Jolt.js / nRF52832:
NRF.setConnectionInterval(100), NRF.sleep(), then periodic neopixel.write — you want ~60 µA again, and no freeze after many cycles.

If anything still misbehaves on a specific chip (e.g. nRF52833 built as 52832), say which board and we can extend the #if or tune the timeout.

Ai Response end

diff --git a/targetlibs/nrf5x_12/components/drivers_nrf/i2s/nrf_drv_i2s.c b/targetlibs/nrf5x_12/components/drivers_nrf/i2s/nrf_drv_i2s.c
index 82f27ce02..cbb45d4f9 100644
--- a/targetlibs/nrf5x_12/components/drivers_nrf/i2s/nrf_drv_i2s.c
+++ b/targetlibs/nrf5x_12/components/drivers_nrf/i2s/nrf_drv_i2s.c
@@ -288,13 +288,38 @@ void nrf_drv_i2s_stop(void)
 {
     ASSERT(m_cb.state != NRF_DRV_STATE_UNINITIALIZED);
 
+    /* i2s_ws2812b_drive_xfer + uninit both call stop; second call must no-op.
+     * Otherwise TASK_STOP + wait on already-disabled I2S can hang (9mA). */
+    if (m_cb.state != NRF_DRV_STATE_POWERED_ON)
+    {
+        return;
+    }
+
     // First disable interrupts, then trigger the STOP task, so no spurious
     // RXPTRUPD and TXPTRUPD events (see FTPAN-55) will be processed.
     nrf_i2s_int_disable(NRF_I2S,
         NRF_I2S_INT_RXPTRUPD_MASK | NRF_I2S_INT_TXPTRUPD_MASK);
 
+    nrf_i2s_event_clear(NRF_I2S, NRF_I2S_EVENT_STOPPED);
     nrf_i2s_task_trigger(NRF_I2S, NRF_I2S_TASK_STOP);
 
+#if defined(NRF52832_XXAA) || defined(NRF52840_XXAA)
+    /* FTPAN-194 (nRF52832): I2S STOP leaves internal state that draws extra
+     * current (~600µA) after system sleep until the next transfer. Same
+     * workaround as nrfx (SDK17+): must run after TASK_STOP but before
+     * nrf_i2s_disable — writing these after disable caused lockups. */
+    *((volatile uint32_t *)((uint32_t)NRF_I2S + 0x38)) = 1;
+    *((volatile uint32_t *)((uint32_t)NRF_I2S + 0x3C)) = 1;
+#endif
+
+    {
+        uint32_t timeout = 10000000UL;
+        while (!nrf_i2s_event_check(NRF_I2S, NRF_I2S_EVENT_STOPPED) && (--timeout) != 0)
+        {
+        }
+    }
+    nrf_i2s_event_clear(NRF_I2S, NRF_I2S_EVENT_STOPPED);
+
     nrf_i2s_disable(NRF_I2S);
 
     m_cb.state = NRF_DRV_STATE_INITIALIZED;
diff --git a/targets/nrf5x/i2s_ws2812b_drive.c b/targets/nrf5x/i2s_ws2812b_drive.c
index e695586ac..7f07f0ac4 100644
--- a/targets/nrf5x/i2s_ws2812b_drive.c
+++ b/targets/nrf5x/i2s_ws2812b_drive.c
@@ -164,7 +164,7 @@ ret_code_t i2s_ws2812b_drive_xfer(rgb_led_t *led_array, uint16_t num_leds, uint8
 	// as far in advance as it can.
 	while (i2s_ws2812b_drive_flag_buffer_cnt < 5);
 
-    // finally, stop the output
+    /* Stop + FTPAN-194 workaround + wait for STOPPED: see nrf_drv_i2s_stop(). */
     nrf_drv_i2s_stop();
 
 	// un-initialize i2s

[gfwilliams]

Well, I think the question is really: Have you tried this and does it work reliably now?

If it does work then great! I'm very happy to have code changes suggested by AI as long as they're good and they work, but at the same time I really don't want people to start posting on all the open issues with "AI suggested you do this. I can't be bothered to try it but I think you should."

Me putting the code change in targets/nrf5x/i2s_ws2812b_drive.c was an attempt at not messing with Nordic's SDK but actually looking at it again, the AI is right about nrf_i2s_disable - SDK12 calls nrf_i2s_disable and SDK17 doesn't - so either way I'd have to modify the SDK12 code.