Search Results

I've removed the API instrumentation, and it now works about 80% of the time in conjunction with the debugger. If I need API instrumentation, I have to run without the debugger (in which case it works fine - and even supports the RTT terminal channel). Obviously annoying, but I'll have to live with it.

It depends what you mean by 'larger chunks'. If you mean my target instrumentation writing large chunks to the RTT buffer, then the answer is no. I'm using the standard instrumentation calls. If you mean the JLink probe or DLL returning larger (completely filled) buffers when being read by JLink Commander, then yes. But remember that this only happens (or only happens to such an extent that it prevents SystemView from working) when SystemView connects via JLink (or JLinkGdbServer). * When System…

OK, it works with your LED blinker. So evidently my software is doing something wrong - but only just wrong enough such that it works when SystemView connects exclusively. Here's the JLink log for my program: Source Code (38 lines)So it looks like the RTT control block is being located and parsed OK, and the various buffers, labels etc located & read. It would appear the problem is associated with the following: T3518 028:948.550 JLINK_RTTERMINAL_Read(BufferIndex = 1, BufferSize = 0x00002800) T3…

Quote from Nino: “So if you connect to your target with J-Link Commander, let the application run with command "go" and then start SystemView, can you confirm that SystemView is working then? ” No, that doesn't work either. Note that connecting Commander doesn't halt the target, but issuing 'halt' and 'go' commands doesn't change the results. But in these further experiments I've found that the problem is not restricted to SystemView. I have a terminal configured on RTT channel 0, which works fi…

Quote from Nino: “Your GDB session needs to have a target connection open and the application must be running. If you then open and connect SystemView it should work. We tested this with the J-link GDBServer and the gcc GDB client and everything is working as expected. Can you confirm that this works for you as well? ” No, this doesn't work. I connect and run the target via the J-link GDBServer, and while it is connected SystemView fails. In order to use SystemView I have to disconnect the debug…

According to the documentation: Quote: “Q: Can I use the SystemView Application while I am debugging my application? A: Yes. SystemView can run in parallel to a debugger and do continuous recording. To make sure data can be read fast enough, configure the debugger connection to a high interface speed (≥ 4 MHz). ” I'm running SystemView on Windows 10, and when no other JLink client is running I can monitor the target (RP2040) with no problem. But if another JLink client is running (for example, J…

Quote from SEGGER - Alex: “You also need to distinguish C-level stepping and assembly single stepping. While a single step on assembler level have interrupts disabled, a C-level step (step over, step-into, ...) has interrupts enabled. For assembly step-over operations, interrupts are also enabled. ” Of course there's another factor involved, which is how the debugger (in my case VSCode cortex-debug & GDB) translates source-level stepping into J-Link commands. From what I've observed, it appears …

Replying to my own post here. It turns out that my original observations were a bit sloppy - this behaviour is simply due to interrupts (including PendSV) being disabled during all step operations. As soon as any kind of run is invoked (including run to the very next instruction) the PendSV is immediately serviced.

I'm using the J-Link 4.95d Beta software to debug an RP2040. As per this StackOverflow question, I've found that single-stepping an instruction that writes to the PENDSVSET flag causes the PendSV to register as pending, but to never enter the PendSV handler. As can be seen, PENDSVSET reads as set and VECTPENDING reads as 0xe - indefinitely, regardless of stepping and/or free-running subsequent instructions (at least until another exception occurs). [img]https://i.stack.imgur.com/i4P6H.png[/img] …