Hi all!

I've recenly got my J-link edu and I've stumbled upon something weird regarding SWO output.

When I try to enable SWO using "monitor SWO EnableTarget 16000000 1000000 3 0" it say's "SWO enabled successfully." though nothing visible happens. Here are my observations:
- SWO line is low, i.e. inactive (should be high be default)
- TPIU registers have sensible values, i.e. NRZ mode is enabled, prescaller is set to 15, formatting is disabled
- ITM registers have sensible values, i.e. it's enabled and stimulus ports 0 and 1 are on,
- PB3 (SWO pin on this MCU) - is set to alternate 0 (as it should), is set to "Very high" speed

So I try SWOViewer and it shows nothing, BUT when I monitor the SWO line it works (the MCU sends proper data). When I turn off the SWO viewer it must set ITM ENA register to 0, cause the data stops flowing, but:
- When I then try to attach with GDB to the MCU, SWO is working
- When I issue command "monitor SWO EnableTarget 16000000 16000000 3 0" (notice now 16MHz SWO clock) the MCU still sends using 1MHz clock, but J-link now expects 16MHz clock, so I see no data on PC side. Though I can confirm that MCU sends data on osciloscope
- What is weirder the ACPR register correcly has now prescaller "0", in fact if I change it manually it doesn't change anything.
- But if I use SWOViewer again with arguments that will set prescaller to 0 it correctly changes the prescaller and now I can use GDB with SWO client again.
- Whatever SWOViewer does, that GDB server doesn't do is effective until next power on reset.

Any ideas what might be the cause of this problem?

My setup:
- STM32H750VB target MCU, currently at 16MHz
- SWD + SWO interface
- VS Code with cortex-debug extension (Basically J-link's gdb server)
- J-link software version 6.38b

Hi,
Thank you for replying!


Yes it should be 6.83b, sorry for that.

The effect is the same as with 16MHz 16MHz setting. I've tried the same procedure as before:

• test with freshly powered on target - no output is generated
  
• enable 1MHz SWO with SWO Viewer - this causes the MCU to start outputing data
  
  • Try your command, I would expect the SWO data to switch to 16MHz - MCU still outputs at 1MHz, no data on GDB's raw swo port
    
  • Try command monitor SWO EnableTarget 16000000 1000000 0xFFFFFFFF 0 - MCU still outputs at 1MHz, GDB is now outputting swo data
    
• power cycle target, enable 16MHz SWO with SWO Viewer - again, this works
  
  • Try your command - MCU still outputs at 16MHz, GDB outputs SWO data
    

Well, on channel 0 I'm sending log output/character bytes (without packing, 2-bytes per character, i.e. ITM header and data byte). Without printf though, as I'm excplicitly not using standard c library.
That doesn't matter though, as I only really care about raw SWO output that your gdbserver provides.


It looks like SWOViewer is doing some configuration of the MCU that gdbserver is not, though I can't pinpoint the issue by just looking at the registers. It doesn't help that ARM's documentation is scattered around multiple documents that reference each other... I'm actually tempted to sniff SWD lines to find the difference, though I don't think I have that much spare time.


BTW. I see I didn't mention it in OP, but in case it matters I'm working on Ubuntu 20.04.
I just tested it on my laptop and the same thing happens there (Windows 10, software version 6.82b).


EDIT:
Just for clarification, when I'm running SWO Viewer I'm using the following arguments: -device STM32H750VB -swofreq 16000000 -cpufreq 16000000
But it also works when I only give it device.

Hi Fabian,

I know that this isn't support system and I can't expect any timeline here, but do you have any news?
If nothing else I'd like to remind you of this issue, as I tried and failed again to find exactly what SWO Viewer does that neither I (manually configuring SWO though registers) nor gdbserver does,

Oh, thanks for the pointer, I was looking for such software and didn't find any so I created my own parsers.

I'll try your instructions in a couple of days, if I find anything related to this problem I'll post it here.