nRF5340 behaves like LDO mode while DCDC mode is configured

[Ben_Squar3d]

Hi,

We are facing a strange behavior where the consumption we measure on the nRF5340 doesn't change according to supply voltage like it is supposed to do in DCDC mode. 

This behavior seems to indicate the nRF5340 is running in LDO mode, but the registers shows that we are supposed to be in DCDC mode : 

Our wiring diagram is the following (same as product specification v1.6, chapter 9.3.1 Circuit configuration no. 1 for QKAA aQFN94) : 

We need help to understand this behavior. 

Thank you very much

Best regards

[Kenneth]

Hello,

I can see you are debugging, in debug mode the chip will stay in LDO mode, this to ensure that programming and debugging can occur even when there is no DCDC available. I suggest you do a hard reset (power cycle) and measure the current then.

Kenneth

[Ben_Squar3d]

Hi,

Thank you for your quick answer. The consumptions are mesured in release mode, not debug mode. How to verify the values of the register without being in debug mode?

[Kenneth]

It should be possible to read the register and output it to uart using log module.

I assume you have a DK for comparison, so can you just verify that the example do work there?

Can you check that in your zephyr.dts file from build folder it says "regulator-initial-mode = < 0x1 >;" for both vregmain and vregradio?

Also, can you just double check that the firmware do enter idle mode (e.g. few uA) between radio activity?

Kenneth

[Ben_Squar3d]

dts file is correct : 

The firmware do enter in idle mode but not few uA. Between 60uA and 300uA regarding nRf5340 chip lot (other ticket pending on this). In the firmware we have the wifi stack and the QSPI enabled which adds around 50uA or so so floor consumption is correct on chip with 2022 date code, and erratic with 2024 date code (investigation in progress, this is not the purpose of this ticket). 

We are in production state, the firmware is no longer compatible with DK at this stage of developpment.

I previously looked at NS register from PERIPHERAL views but we are actually running in secure mode so I checked NRF_REGULATORS_S registers like this : 

	if(NRF_REGULATORS_S->VREGMAIN.DCDCEN == 1 && 
		NRF_REGULATORS_S->VREGRADIO.DCDCEN == 1 &&
		NRF_REGULATORS_S->VREGH.DCDCEN == 1) 
	{
		lErr = module_usb_enable();
		FATAL_ASSERT(lErr == SUCCESS);
	}

Basically, I mount the USB if these are correctly set, just for test purpose. This test pass so register are being configured correctly. How to verify I am not still in debug mode, despite not having CONFIG_DEBUG=y ?

EDIT : I just noticed that both in our release and debug build, (we set CMAKE_BUILD_TYPE to Debug) we still have this:

#
# Debugging Options
#
# CONFIG_DEBUG is not set
# CONFIG_STACK_USAGE is not set
CONFIG_PRINTK=y
CONFIG_EARLY_CONSOLE=y
CONFIG_ASSERT_LEVEL=2
# CONFIG_FORCE_NO_ASSERT is not set
CONFIG_ASSERT_VERBOSE=y
# CONFIG_ASSERT_NO_FILE_INFO is not set
CONFIG_ASSERT_NO_COND_INFO=y
CONFIG_ASSERT_NO_MSG_INFO=y
# CONFIG_ASSERT_TEST is not set
# CONFIG_OVERRIDE_FRAME_POINTER_DEFAULT is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_THREAD_INFO is not set
# CONFIG_DEBUG_COREDUMP is not set
# CONFIG_SYMTAB is not set
# end of Debugging Options

In the .conf file

[Kenneth]

Hi,

Just to make sure there is no misunderstanding, when I commented on "debug mode" I am not thinking of the setting of CONFIG_DEBUG. But I am just saying that when the chip is programmed it will stay in "debug mode" until a hard reset (power cycle). But I assume you are performing power cycles between programming and measurements here.

Also it could be interesting to try LDO configuration in the devicetree instead of DCDC for comparison, just in case it's actually is using DCDC. I know the spikes in the online power profiler are a bit averaged and the ppk also likely jump between two measurement ranges here (~5mA, which unfortunately has shown can cause the measurement to be wrong in some cases), both could explain potentially the first transient is higher.

If you are using VDDH mode then the supply voltage range is 2.5-5.5V, and the current consumption will not be the same as the online power profiler (which use VDD mode 1.7-3.6V), ref:
https://docs.nordicsemi.com/bundle/ps_nrf5340/page/chapters/recommended_op_conditions/doc/recommended_op_conditions.html 

So that might also be part of the reason.

Also see the difference in the supply configurations here (VDDH vs. VDD):
https://docs.nordicsemi.com/bundle/ps_nrf5340/page/chapters/ref_circuitry.html 

You should also check what the voltage output from VDDH to VDD is configured:
https://docs.nordicsemi.com/bundle/ps_nrf5340/page/chapters/uicr/doc/uicr.html#register.VREGHVOUT 

I notice you have EXTSILENTEN enabled, do you feed external circuitry from VDD?
https://docs.nordicsemi.com/bundle/ps_nrf5340/page/regulators.html#ariaid-title13 

I can try to ask a colleague tomorrow that do current consumption measurements if he can comment in specific, but would be good if you can comment on the above first.

Kenneth

[Ben_Squar3d]

Kenneth said:

If you are using VDDH mode then the supply voltage range is 2.5-3.6V, and the current consumption will not be the same as the online power profiler (which use VDD mode 1.7-3.6V)

Still, if we are in DCDC mode, the consomption must change according to supply voltage right? Here it is not the case.

Kenneth said:

Also see the supply configurations here (VDDH vs. VDD):
https://docs.nordicsemi.com/bundle/ps_nrf5340/page/chapters/ref_circuitry.html 

see : 

Ben_Squar3d said:

Our wiring diagram is the following (same as product specification v1.6, chapter 9.3.1 Circuit configuration no. 1 for QKAA aQFN94) : 

Kenneth said:

I notice you have EXTSILENTEN enabled, do you feed external circuitry from VDD?

Yes we do.

Kenneth said:

Just to make sure there is no misunderstanding, when I commented on "debug mode" I am not thinking of the setting of CONFIG_DEBUG. But I am just saying that when the chip is programmed it will stay in "debug mode" until a hard reset (power cycle). But I assume you are performing power cycles between programming and measurements here.

Yes I do perform power cycle between measurments. My point is, if the nRF53440 is in LDO mode despite the registers being configured in DCDC mode when it is in debug, then I must be SURE we are not in debug mode. How can I do? 

Thank you

[Kenneth]

Can you please do the measurements with LDO for comparison?

Also please specify the output voltage you have when using VDDH.

Kenneth

[Kenneth]

The first radio spike you are focusing on can be explained by: "I know the spikes in the online power profiler are a bit averaged and the ppk also likely jump between two measurement ranges here (~5mA, which unfortunately has shown can cause the measurement to be wrong in some cases), both could explain potentially the first transient is higher."

Kenneth

[Kenneth]

One final comment for today: I am wondering actually that when radio startup it may be indirectly charging C31, that can also add to the initial spike you see there. 

Kenneth

[Ben_Squar3d]

Kenneth said:

The first radio spike you are focusing on can be explained by

All the spikes are around 14mA, not only the first one. This value is typical from the LDO configuration shown in the profiler.

I did measurement with LDO enabled, and the results are almost the same : BLE spikes are around 15mA and does not change according to supply voltage (same case as before, but now consistent with profiler estimation), but the floor consumption increased from 150uA to 400uA.

Output voltage is set to 1V8.

[Kenneth]

I can try to measure myself next week on a DK for comparison.

I was thinking that the green peaks are not that far off the online profiler:

And that the red spike is caused by either:

- measurement error due to ppk change measurement range from <5mA to >5mA
- transient due to charging of C31 (will likely occur in both LDO and DCDC mode)

If you say that you see no difference in the green spikes when going from DCDC to LDO, then it sounds like it's something else problematic here that we can't see. The schematic looks good as far as I can see. 

Next step would be to try a simple BLE beacon example from the SDK for comparison, that should be able to run on any hardware.

Kenneth