SPIM3 transfer raises sleep current by 700 uA from then on

RE: SPIM3 transfer raises sleep current by 700 uA from then on

Saxman58 — Thu, 01 Oct 2020 12:23:30 GMT

I replaced the register write with

nrfx_spim_uninit(&spi);

and that worked. That also makes it more universal to work with any SPIM module selected for spi. Thanks!

RE: SPIM3 transfer raises sleep current by 700 uA from then on

Stian Røed Hafskjold — Thu, 01 Oct 2020 12:11:43 GMT

The SPIM3 HW implementation is in fact a bit different than SPIM0-2 (because of some resource sharing with TWI), so I suspect that the problem is due to some HW issues which are only present in SPIM3. I will report this internally so that we can try to figure out what is going on here. Anyways, I think it is good practice to disable the peripheral manually when not in use. You can check out the nrfx_spim_uninit() function, which should be equivalent to using the ENABLE register. I also think it is good practice to stick with the nrfx driver and avoid using registers directly (unless it's required by the errata workarounds). So if you can try the nrfx_spim_uninit() function with SPIM3 and see if that solves the issue instead of using the ENABLE register, I think that would be better. Or at least run the nrfx uninit before the register write, so that the driver is properly uninitialized first.

RE: SPIM3 transfer raises sleep current by 700 uA from then on

Saxman58 — Thu, 01 Oct 2020 11:25:56 GMT

Yes, it is definitely the nRF52833. I just tried adding NRF_SPIM3->ENABLE = 0 to the end of the SPI transactions (without the extra register write in the workaround) and that was enough to get rid of the extra 700 uA.

As you can see, I was using higher level code rather than direct register writes, and I didn't see any function to disable an SPI like that direct register write does. Since SPI0, 1, and 2 seem to stop using current when they aren't in use, I assumed they were somehow being shut down by the SoftDevice or something. Should I be using the ENABLE register to shut them down too? It is curious that only SPIM3 continues to use current after a transfer with exactly the same code. Does that indicate that some code in the SoftDevice for SPIM0-2 needs to be extended to SPIM3 as well?

Anyway, the ENABLE register solve my problem, so thank you!

RE: SPIM3 transfer raises sleep current by 700 uA from then on

Stian Røed Hafskjold — Thu, 01 Oct 2020 11:00:09 GMT

So the chip you are using is actually nRF52833, not nRF52840? The reason I ask is because your description fits well with this errata: https://infocenter.nordicsemi.com/topic/errata_nRF52840_Rev2/ERR/nRF52840/Rev2/latest/anomaly_840_195.html?cp=4_0_1_0_1_26

But it should be fixed on nRF52833. Anyways, maybe you can try the workaround and see what happens?