Hi,
I am using a SEGGER J-Link with Ozone to debug my RP2350 system. I am using LVGL v9.4 (latest release as of today) on this board: https://www.waveshare.com/2inch-capacit ... ch-lcd.htm and my development system is running Ubuntu 24.04 with pico-sdk 2.2.0.
When programming the system via Ozone (ie via the J-Link), LVGL is extremely sluggish at runtime. If I disconnect the debugger (by closing the debugger software, or even physically by unplugging the SWD cable) it remains the same speed (100-200ms to render a frame).
However, if I hard reset or power cycle the system, the same code can now render the same frame in around 10ms.
Does programming via or attaching the debugger do anything to "permanently" disable caches, slow down internal bus clocks, etc? I normally use ARM MCUs from many other manufacturers this way (ST, Nordic, etc) and have never encountered this problem. It's also a little worrying because a lot of production jigs I have made previously use J-Link programmers to flash test firmwares, but it seems like this will not be OK for the RP2350. I am also a heavy user of SEGGER RTT, but again I seemingly can't attach a debugger without causing this issue.
I am running the RP2350 at 200MHz and the SPI bus at 100MHz (fed via DMA) if that is relevant.
Thanks,
Jeremy
I am using a SEGGER J-Link with Ozone to debug my RP2350 system. I am using LVGL v9.4 (latest release as of today) on this board: https://www.waveshare.com/2inch-capacit ... ch-lcd.htm and my development system is running Ubuntu 24.04 with pico-sdk 2.2.0.
When programming the system via Ozone (ie via the J-Link), LVGL is extremely sluggish at runtime. If I disconnect the debugger (by closing the debugger software, or even physically by unplugging the SWD cable) it remains the same speed (100-200ms to render a frame).
However, if I hard reset or power cycle the system, the same code can now render the same frame in around 10ms.
Does programming via or attaching the debugger do anything to "permanently" disable caches, slow down internal bus clocks, etc? I normally use ARM MCUs from many other manufacturers this way (ST, Nordic, etc) and have never encountered this problem. It's also a little worrying because a lot of production jigs I have made previously use J-Link programmers to flash test firmwares, but it seems like this will not be OK for the RP2350. I am also a heavy user of SEGGER RTT, but again I seemingly can't attach a debugger without causing this issue.
I am running the RP2350 at 200MHz and the SPI bus at 100MHz (fed via DMA) if that is relevant.
Thanks,
Jeremy
Statistics: Posted by jerh — Sun Oct 19, 2025 11:12 pm