I am currently making some kind of strange observation:

When using a J-Link debugging probe (using Segger Ozone) and placing a breakpoint into the function nrf_uarte_disable(), located in the nrf_uarte.h file, then the power consumption goes down to the expected 130 uA after suspending the uart device with pm_device_action_run( uart0Device, PM_DEVICE_ACTION_SUSPEND );

When switching off the power supply and switching on again … doing a startup without breakpoint … the power consumption ends up at about 550 uA.

For me this seems to be some kind of race-condition, but I am using only the one main thread. Up to now I was not able to investigate if there are some other zephyr initialization/startup threads, which might get scheduled in a different order, when debugger is in play.

I would appreciate any suggestion or tip, of how I should/can proceed to investigate this further!?

Volker

Hi Jeremy,

thank you for this suggestion.

A compiler warning showed me, that the old kind of pin-configuration is now deprecated and then I found out, that I have to use pin-control now. But unfortunately this did not help.

Volker

Hi,

From the logs its seems that the underlying `send()` call on the TCP socket failed – oddly enough, it takes place in the middle of the handshake, so it doesn’t seem to be a problem with your qemu internet connection. Unfortunately I’m not able to reproduce the issue on my side.

I’d try to log the actual `errno` value returned by the `send()` call when the failure takes place (https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/lib/sockets/sockets_tls.c#L847) – that should give some brief information about the reason of the failure.

I would also recommend checking the packet flow with Wireshark (you can monitor the `tap0` interface) – maybe the server decided to abruptly close the connection for some reason.

Regards,

Robert

Hi Jeremy,

thank you for this suggestion.

A compiler warning showed me, that the old kind of pin-configuration is now deprecated and then I found out, that I have to use pin-control now. But unfortunately this did not help.

Volker

Hi,

I am working on a custom hardware containing a nrf52840 and some peripherals.

I am now upgrading from zephyr 2.4 to zephyr 3.1 and experiencing a significant power consumption increase.

When using zephyr 2.4 I was able to reduce the overall idle power consumption to about 70 uA while still doing periodic Bluetooth-le broadcasting.

After upgrading to zephyr 3.1 the idle power consumption is now at about 550 uA.

To track down to the root-cause I removed all application code, now having a main loop which is doing only sleep calls.

When removing all configured components I was able to reduce to 130 uA. But as soon as I add the Uart to the config (CONFIG_SERIAL=y) the power consumption goes up to 550 uA. Even when actively trying to put it into suspended mode.

Can anybody give me some advice of how to investigate where the increased power consumption comes from?

Regards,

Volker

I don’t think you need to create your own backend if you are willing to send a PR or carry an out-of-tree patch. As long as your backed of choice is using log_output_msg_process():

From what I can tell you would need to modify timestamp_print() in log_output.c. You could propose a patch to reformat the timestamp based on Kconfig options.

If you don’t want to send a patch upstream you can probably just modify that function yourself locally.

Carles

Hi,

Log_output module has timestamp formatting functionality. It is a helper module that is used by most of the backends. Processing function accepts flags and one is LOG_OUTPUT_FLAG_FORMAT_TIMESTAMP. If you want different formatting then you can try to extend log_output or implement it directly in your own backend.

Regards,

Krzysztof

Hello!

Is it really necessary to implement an entire logging backend just to achieve custom timestamp formatting?

I was hopeful when I came across CONFIG_LOG_BACKEND_FORMAT_TIMESTAMP.  But this is just a boolean, not a format string.

I want my log messages to be prefixed with date and time.  Now I wonder, is it a bad idea?  Why else would such functionality be missing?

Cheers,

Gordon

Hi all,

Exactly as the subject line says, is it possible to configure the master clock frequency of an I2S peripheral in the device tree?  I’m using an nRF5340.  I can see that there’s a clock-source property in nordic,nrf-i2s, which I can set to ‘ACLK’, and then configure the frequency of that clock in the nordic,nrf-clock node, but I’m stumped after this.  It seems like there’s no place to set the prescaler value .mck_setup for nrfx_i2s_config_t.  Is there any way to control this property as well from devicetree, or is this all better suited as a kconfig option.

Thanks,

• Jason

Hi Nash,

Is this a new installation of WSL Ubuntu, or one that’s been used for other purposes for a while?  I ask because I believe the errors you’re seeing are due to those packages already existing on your system but at a different, incompatible version number.  Pip is refusing to upgrade or downgrade these packages as it doesn’t want to break other applications that listed these packages as dependencies.

Rather than using the “install globally” instructions, you could try using a python virtual environment (“install with virtual environment”, on the getting started page).  Essentially, venv creates a directory at the root of your project and looks there for site-packages first.  Now, when you install packages through pip, they should get installed there instead of replacing the packages already installed in your normal python site-packages directory.  Remember to activate the virtual environment (.venv/bin/activate) when you want to do any work on this project, or you’ll end up using the wrong packages, and that could cause your build to fail.  My personal recommendation is to use a virtual environment for any project that requires packages from pip.

Another, less recommended option, would be to loosen the version number restrictions in requirements.txt.  It looks like most of your errors are caused by pip complaining that your currently-installed packages are too new.  You can open up the requirements.txt file and modify the required min and max version numbers there.  Note that this is probably a bad idea in the long run, especially if you relax the minimum version requirements, but may get you up and running in the short term.

Hopefully that helps you get started,

• Jason