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

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

Susheel Nuguru — Wed, 05 Feb 2025 18:17:59 GMT

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.

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

esmart-engineering — Tue, 04 Feb 2025 06:24:54 GMT

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?

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

Susheel Nuguru — Mon, 21 Oct 2024 05:11:13 GMT

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

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

esmart-engineering — Fri, 18 Oct 2024 17:06:16 GMT

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?

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

Susheel Nuguru — Fri, 18 Oct 2024 06:55:30 GMT

[quote user=""]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.[/quote]

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.