nRF52833 spi nor causing extra current ~300uA

RE: nRF52833 spi nor causing extra current ~300uA

Simonr — Thu, 03 Aug 2023 12:08:37 GMT

I have contacted the IC product support team to see if we have more to add to this. Hopefully we'll be able to add some information on why SPI3 doesn't behave the same as the others and what you can do to implement a good workaround.

Best regards,

Simon

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Wed, 02 Aug 2023 13:11:17 GMT

Simon,

So what I am hearing is that the spi3 device is not properly managed for power in either zephyr or mcuboot as it is a high speed peripheral and there is only one spi driver that does not take that into account. The fact that I have to manually power manage the spi3 just like the errata on the nrf53840 makes me think that there is a bug in the code or that there is an errata. Either way this does not happen with the other spi ports so it would be expected that spi3 would have the same level of power management.

To use spi3 in any way it has to be manually shut down using either of the below calls with the top one being from the nrf52840 errata. The issue I have with the mcuboot utils is that I dont know when it is going to run the check as it does it on next connection. The only workaround i could think of is to disable the spi after every connection which is not ideal and the mcubootutil is a library so i would have to do a lot of digging to find where to edit and hope i can make any pm call in mcuboot code.

I would imagine for this type of peripheral some sort or semaphore would be used like the one used for the external clock being enabled and disabled. At this point it seems spi3 is not useful since it has to be manually shut down every time it is touched.

*(volatile uint32_t *)0x4002F004 = 1;

#if DT_NODE_HAS_STATUS(DT_NODELABEL(spi3), okay)
pm_device_action_run(spi_dev, PM_DEVICE_ACTION_SUSPEND);
#endif

RE: nRF52833 spi nor causing extra current ~300uA

Simonr — Wed, 02 Aug 2023 12:49:42 GMT

Sorry about the late reply, but we're not able to find anything in the MCUBoot or low power mode that should be leaving the SPI3 instance on after use if it's shut down correctly. I think this should be possible to solve in your application, by finding out which check is running and do some cleanup on the SPI3 instance.

I also did some digging to see if there were any errata on the nRF52833 or v2.0.0 of the NCS that could cause this, but the only one I could see causing this is the unexpected wakes from System ON idle mode if you're using the FPU.

Best regards,

Simon

RE: nRF52833 spi nor causing extra current ~300uA

Simonr — Tue, 25 Jul 2023 07:15:52 GMT

Okay, waiting for a reply in the internal ticket with our devs. I'll let you know when I hear back from them.

Best regards,

Simon

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Fri, 21 Jul 2023 10:39:12 GMT

That is correct after mcuboot finishes once you reconnect via ble it runs some sort of utility check and checks the swap which leaves the spi on

RE: nRF52833 spi nor causing extra current ~300uA

Simonr — Fri, 21 Jul 2023 07:42:36 GMT

Sorry, I'm just trying to get this straight so we can get to the bottom of this most efficiently. The SPI3 is only used by the MCUBoot in your project, is that so? And MCUBoot is using this to communicate with an external flash. And after it's done communicating with it it just does not go to a low power mode?

Best regards,

Simon

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Wed, 19 Jul 2023 11:58:30 GMT

Simonr

I do believe you are mistaken as this is happening after it boots into zephyr and after BLE connection is reestablished to the phone. If it were merely before zephyr then the pm call suggested above would have been adequate as I do not use spi3 in my code and it is only for mcuboot. It is waking back up and what I see in the rtt log is that mcuboot_util is checking swap type. I have no control over that code as it is brought in as a library. It also does not happen in the most deterministic way so it would be hard to see how that would help.

Looking at what you intend to be modded the fact that is in mcu boot would require me to patch the sdk and as stated this is happening while in zephyr the spi is low power untill mcuboot_util as shown and stated in my post from 2 weeks ago.

RE: nRF52833 spi nor causing extra current ~300uA

Simonr — Wed, 19 Jul 2023 11:46:14 GMT

Hi Edward

[quote user="edmcnicholas"]Well how would this call be triggered as the power comes back after the phone reconnects to the module not right after boot.[/quote]

If that's the case, we struggle to see how this is an MCUBoot issue.

Excuse me if I've misunderstood, but isn't your issue that when your MCUBoot goes to low power, it re-enables SPIM3 causing this extra current consumption?

If the device is set in a low power state and goes through MCUBoot, then enabling clean up may affect it (You will have to implement clean up for the SPI). If clean up is not enabled, MCUBoot may leave the peripheral in an undesired power state. But if you're not willing to investigate this possibility, the issue might as well be in the device tree, power management system of Zephyr, or your application. We're just trying to narrow down what exactly causing this issue.

It could also be that you need to configure the MCUBoot to set SPI NOR to have the same config as in the application, as child images don't automatically inherit settings from DTS exclusively. If it's a DTS overlay you need to also make a child image overlay with the same SPI config or a Kconfig overlay.

Best regards,

Simon

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Mon, 17 Jul 2023 11:50:39 GMT

Well how would this call be triggered as the power comes back after the phone reconnects to the module not right after boot.

RE: nRF52833 spi nor causing extra current ~300uA

Simonr — Mon, 17 Jul 2023 11:47:24 GMT

I got a suggestion from the developers today. Have you enabled peripheral clean-up in MCUBoot? Perhaps some form of SPI cleanup needs to be added into this file if external flash with an SPI node is enabled as it probably uses Zephyr's subsystem to enable it. This could be a different configuration than what you expect it to be configured in.

https://github.com/nrfconnect/sdk-mcuboot/blob/main/boot/zephyr/nrf_cleanup.c

Best regards,

Simon

RE: nRF52833 spi nor causing extra current ~300uA

Simonr — Tue, 11 Jul 2023 13:08:23 GMT

Due to the summer vacation period we are currently understaffed, so delayed replies must be expected. I am sorry about any inconvenience this might cause. Håkon is currently on vacation now, and I have been assigned to this case in his place. And it took me a while to read up on your discussion.

I'm not an expert on MCUBoot or what it is doing, but I have asked internally if one of the developers have an explanation to what is going on here and whether the workaround you suggest or something similar is already added to the newer SDK versions or if we will have to do so.

Best regards,

Simon

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Thu, 06 Jul 2023 15:10:53 GMT

I don't believe it has anything to do with the flash but it has to do with mcuboot checking something under the hood after an update. The suspend works but mcuboot is waking it back up. I did update firmware to check function and after the reconnection of bluetooth to the nrf connect app the mcuboot utility runs something under the hood. i tried to search but this is compiled into the mcuboot library and is supplied to my project as binary.

As for updating sdk that is planned but there is a lot uf custom code and the project configs keep changing a lot between releases making this a time-consuming task.

The really crazy part is the power going away when i enable the rtt terminal.

The only workaround I can think of for this is add a delayed suspend at boot to ensure the spi goes to sleep. If this is not managed in this or a later sdk then spi3 is basically an unusable peripheral with zephyr and with it being the only high speed spi this seems to be the peripheral that would be intended for spinor updates.

RE: nRF52833 spi nor causing extra current ~300uA

Håkon Alseth — Thu, 06 Jul 2023 14:53:22 GMT

Hi,

[quote user="edmcnicholas"]I get a message about swap revert [00:00:01.116,821] <inf> mcuboot_util: Swap type: revert.[/quote]

Is this intended behavior, Ie. did the updated firmware not run and verify itself?

Have you tried running a newer version of NCS to see if the behavior is similar?

[quote user="edmcnicholas"]So after MCUBOOT the device goes to low power for about 1s then something in mcuboot kicks it back on.[/quote]

I understand that mcuboot will communicate with the flash here, especially if it is reverting an image.

It seems very strange that the current consumption comes back after a reboot. Is your application is running PM_DEVICE_ACTION_SUSPEND for both the flash_dev and the spi_dev?

[quote user="edmcnicholas"]There is definitely something wrong down to the driver level at least for spi3. [/quote]

I agree that spim3 is trickier than the other lower speed SPIM modules, especially since the PS also states that the peripheral should be disabled for lowest possible current consumption:

https://infocenter.nordicsemi.com/topic/ps_nrf52833/spim.html?cp=5_1_0_5_22_4#concept_twi_low_power

This is something that Nordic can improve upon, spi_nor/spi_nrfx_spim driver-wise.

Kind regards,

Håkon

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Wed, 05 Jul 2023 20:26:50 GMT

So after MCUBOOT the device goes to low power for about 1s then something in mcuboot kicks it back on. I get a message about swap revert [00:00:01.116,821] <inf> mcuboot_util: Swap type: revert. There is definitely something wrong down to the driver level at least for spi3. This power management should all be handled at the driver level. I even went to the point of trying to add it to the driver but that did not work

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Wed, 05 Jul 2023 13:09:14 GMT

So while that works when I return from mcuboot the power is back and I would have to power cycle the device to get to the appropriate power level.

RE: nRF52833 spi nor causing extra current ~300uA

Håkon Alseth — Wed, 05 Jul 2023 10:17:21 GMT

Hi,

[quote user="edmcnicholas"]It appears likely that there is an inherited errata from the nrf52840 in the nrf52833 given their similarities. I applied the workaround for errata 195 on the nrf52840 and the power went away. This is a rev 1 nrf52833 that I am working with so it is likely engineering needs to investigate all nrf52840 spim spi3 errata on the nrf52833.[/quote]

The workaround in Errata #195 for nRF52840 will effectively suspend the peripheral, which again improves your theory of the added consumption coming from the peripheral.

I am sorry, but I thought my former suggestion also disabled the peripheral, but that is not true. My apologies for this.

My former suggestion only handles your external flash, while keeping the SPIM peripheral enabled.

[quote user="edmcnicholas"]I could try that but that would not explain why it works fine on spi2 and not spi3.[/quote]

NRF_SPIM3 is a high speed peripheral, which is internally in the chip clocked differently compared to the "lower speed" SPIM instances. It will require that you disable it to obtain lowest possible current consumption.

I recreated your current consumption by setting up SPIM3 and sending data in a loop.

When adding pm_device_action_run(spi_dev, PM_DEVICE_ACTION_SUSPEND);, I saw the current drop:

The code is running 1 sec SPIM3 on, 1 sec SPIM3 off:

devzone.nordicsemi.com/.../hello_5F00_world_5F00_spi3.zip

Could you try to disable the SPIM3 peripheral as well using the PM_DEVICE API?

Kind regards,

Håkon

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Tue, 04 Jul 2023 14:36:29 GMT

It appears likely that there is an inherited errata from the nrf52840 in the nrf52833 given their similarities. I applied the workaround for errata 195 on the nrf52840 and the power went away. This is a rev 1 nrf52833 that I am working with so it is likely engineering needs to investigate all nrf52840 spim spi3 errata on the nrf52833.

infocenter.nordicsemi.com/index.jsp

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Tue, 04 Jul 2023 14:19:39 GMT

That has no effect as expected. There is a bug in the spi3 block

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Tue, 04 Jul 2023 13:58:52 GMT

I could try that but that would not explain why it works fine on spi2 and not spi3. I have instrumented the spinor code and get a print that the device is entering deep power down and I do not see it exit. That also would not explain why the power goes away when i connect rtt terminal and returns when i remove it.

RE: nRF52833 spi nor causing extra current ~300uA

Håkon Alseth — Tue, 04 Jul 2023 13:50:47 GMT

Hi,

Could it be that the external flash ic is not set in a low power state?

Could you try to suspend the device using pm_device to see if this has a impact on the current consumption?

pm_device_action_run(my_flash_dev, PM_DEVICE_ACTION_SUSPEND);

Kind regards,

Håkon

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Mon, 03 Jul 2023 19:47:00 GMT

I also tried errata 246 and that did not help. But every time i enable the RTT terminal the power goes down and when I disable it it comes back. This is very odd.

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Mon, 03 Jul 2023 14:57:29 GMT

The power on spi3 also goes back up after removing the debug connection

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Mon, 03 Jul 2023 14:55:35 GMT

No I tried turning off all logging and no change. Once I changed to spi2 the issue went away so I assume it has something to do. With the spi3 block since it is different from the other 3

RE: nRF52833 spi nor causing extra current ~300uA

Håkon Alseth — Mon, 03 Jul 2023 14:52:02 GMT

Hi,

[quote user=""] If I enable the RTT terminal then the extra consumption goes away which is the very odd part. It also goes away if I disable spinor but that is necessary for expanded bootloader space. [/quote]

Does the added current consumption also go away if you only disable RTT?

Kind regards,

Håkon

RE: nRF52833 spi nor causing extra current ~300uA

edmcnicholas — Mon, 03 Jul 2023 13:41:51 GMT

As an update I see that there might be an issue with spi3 or the high speed spi on the nrf52833 implementation as when I move the norspi to spi2 then the extra power goes away. I would prefer to use the high speed spi for the extra throughput but there seems to be a bug in at least the 2.0 version of the sdk.