nRF5340, fastest possible time to disable/re-enable network core

[esmart-engineering]

I found out nrf_reset_network_force_off() can be used to turn on/off the network core in firmware, per the example in NCS v2.5.0, samples/subsys/ipc/ipc_service/icmsg. I would like to use it in optimizing power in a project that needs to wirelessly transmit data every 3ms. From testing out the function in my project, it seems like it takes just about 3ms total to turn off and on the core.

My findings show these approximate times:

Operation	Function Call	Time (us)
Turn On Network Core	(total)	2869.8
	ipc_service_deregister_endpoint()	10.12
	k_sem_init()	1.04
	ipc_service_register_endpoint()	26.88
	nrf_reset_network_force_off(NRF_RESET, false)	9.72
	k_sem_take(&bound_sem, K_FOREVER)	2820
Turn Off Network Core	(total)	86.84
	nrf_reset_network_force_off(NRF_RESET, true)	86.84

I had the following questions:

1. Is there something I can do to have k_sem_take() finish quicker? I'm working on this at the moment, but am open to other tips.
2. Is this more or less the expected time to perform these operations?
3. Are there faster, but less power-efficient ways to lower the power consumption on the network core i.e., put to sleep instead of FORCE OFF?

Thank you in advance for your help!

[Susheel Nuguru]

Is there something I can do to have k_sem_take() finish quicker? I'm working on this at the moment, but am open to other tips.

Haven't tried it but you should be able to see the activities before k_sem_take, if you enable system viewer from segger using the below configs in your prj.conf

CONFIG_THREAD_NAME=y
CONFIG_SEGGER_SYSTEMVIEW=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_TRACING=y
# enable for post-mortem tracing
CONFIG_SEGGER_SYSVIEW_POST_MORTEM_MODE=n

Add 

#include <SEGGER_SYSVIEW.h>
    SEGGER_SYSVIEW_Conf();  // Configure SystemView
    SEGGER_SYSVIEW_Start(); // Start SystemView recording

in your main function and see if the of wait is full use of CPU or of something else was just waiting. If there is a lot of wait before sem_take, you can see the context of which thread was waiting and probably there is some room for optimization there.

The rest of your question will also be answered once you get your systemviewer running with your app.

[esmart-engineering]

Sorry I didn't clarify earlier. My development environment is with Windows 10 and VS Code, not SEGGER. What would the corresponding settings be if I'm using VS Code?

[Susheel Nuguru]

Segger Systemview is something you need to download. VSC does not have anything to see thread contexts in realtime yet. 

[esmart-engineering]

Hello, sorry for the late reply. My company only just brought this topic back up.

I tested adding the config and C code, but was unable to see data appear in SystemView (I downloaded V3.58). I'm using an nRF5340DK, connected/powered via USB. SystemView appears to detect the J-Link via USB, but it will say "Recorder starting..." (and stay at 1%) and then shortly after report "Error starting recorder". My settings were to use J-Link (USB), target connection "CORTEX-M33", target interface SWD (4000kHz), and RTT control block detection at "auto".

Am I missing something in the hardware setup?

[Susheel Nuguru]

It looks like the systemviewer is not able to connect to the device and there can be many reasons that this is happening. Many have succeeded in using Systemview like in this thread. Please follow the guide from the systemviewer and make sure that you follow every step of it.