Search Results

Hello Nino, good to hear that multi-core is already on your wishlist. My target device is an RP2040, so Cortex-M0 dual core. My application is actually running under FreeRTOS. But to my understanding there is no patched FreeRTOS kernel for SystemView available. And anyway... how should it work if it is currently not supported by SystemView!? My first idea was to do it with some manual SystemView calls. But again for multi-core no luck (as you pointed out). Another platform I'm using in the near …

Hello, I'm trying to monitor activity of the two CPUs of an RP2040 (no OS). Unfortunately calling SEGGER_SYSVIEW_OnTaskStartExec() switches graphically away from the other task running (also started with SEGGER_SYSVIEW_OnTaskStartExec()). Is there any way to have two (or more) graphs active in parallel on the timeline or is this limited to one active graph? Thanks Hardy

Hmm, but that indicates, that SEGGER_RTT_LOCK does not work in your situation. Concerning laggy: for me SystemView is working up to several 1.000.000 events, but I guess this depends.

Perhaps you have stumbled into something like my problem, see SEGGER_RTT_LOCK/UNLOCK code wrong? ? Meaning that the SEGGER_RTT_LOCK() is not effective. If the Zephyr code is comparable to SoftDevice, then the BlueTooth interrupts are running with Prio=0. You could try to use the code from __ARM_ARCH_6M__ (or my code) with the nRF52832 to disable interrupts during lock completely.

Haha, my bad. Sometimes it is useful to read comments documenting the source code. And then start thinking. My actual problem was, that I did not initialize the priority of the SysTick interrupt. And reset priority is 0 which means, that SysTick can interrupt SEGGER_RTT_LOCK() which sets BASEPRI to 0x20 on a Cortex-M4. So my "strong" feeling from above was wrong. Learned another lesson H.

Hello, I have the "strong" feeling, that the lock/unlock code in SEGGER_RTT_Conf.h is not correct. At least with nRF52840 without OS, but I think this actually doesn't matter. I'm currently playing around with SystemView and with just a main "thread" (i.e. without interrupts) the SystemView data stream is ok. Events arrive correctly at SystemView and are displayed accordingly. But if there is an additional SystemTick interrupt (123/s), then SystemView eventually shows messed up data like "ISR 17…

I can confirm the behavior under Debian testing: v3.30 works with UART, v3.32 shows described box and then no communication via UART. v3.50a has the same (wrong) effect. Edit: happens with 64bit .deb and portable version as well