09:06 <zapb_> frankplow, what J-Link probe do you have?

09:07 <zapb_> frankplow, a fatal error in the emulator should not happen

10:41 <frankplow> zapb_: It's the J-Link OB firmware running on the nRF5340 interface MCU of the nRF52 DK

10:42 <PaulFertser> frankplow: please use some pastebin to show full -d2 log of an attempt.

10:44 <frankplow> zapb_: Re. the error itself: the GDB server seems completely fine, the only thing which does not work is the SWV. I think it is an emulator fatal error as I get a 1Hz flash on the interface MCU's indicator LED, which the J-Link manual says indicates a fatal error: https://wiki.segger.com/UM08001_J-Link_/_J-Trace_User_Guide. I am not sure if this indicator behaves the same when using OpenOCD rather than the J-Link software?

10:52 <frankplow> PaulFertser: Here is a -d2 log: https://pastebin.com/FxHqEL22 and here is a -d3 log: https://pastebin.com/eKV2BQg4

10:57 <PaulFertser> frankplow: and how do you create and monitor itm.fifo?

10:58 <frankplow> PaulFertser: I've tried mkfifo, touch and letting OpenOCD create the file itself, and have been monitoring with cat or checking the size with ls -l

10:59 <PaulFertser> frankplow: and do you by any chance have an oscilloscope to see if SWO pin has any transmission when you use it with OpenOCD?

11:00 <frankplow> PaulFertser: Not on hand unfortunately, I can try on Monday

11:01 <PaulFertser> frankplow: probably j-link software does some additional init which is supposed to be performed with firmware itself in OpenOCD case and the signal is just not there.

11:01 <PaulFertser> frankplow: or probably nrf config is indeed missing some configuration for pinmuxing the SWO pin or some other enable action. Have you checked with the datasheet?

11:02 <PaulFertser> frankplow: if you have a reasonable UART adapter you should be able to receive that data even without SWD, just by firmware itself setting everything right.

11:02 <frankplow> Yeah, you have to set a register up for pinmuxing, but I've done that and it works with the J-Link software

11:03 <frankplow> PaulFertser: How do I know what frequency I should be trying if it is not negotiated? I suppose I can do this to see if I get any data in lieu of a scope.

11:03 <PaulFertser> E.g. stm32 MCUs have _proc_pre_enable function in OpenOCD configs which are needed for SWO to be used.

11:04 <PaulFertser> frankplow: jlink software might be doing something extra, just like OpenOCD does with stm32 targets.

11:04 <PaulFertser> frankplow: when you do all the TPIU/SWO configuration in firmware you just set the prescaler.

11:08 <PaulFertser> frankplow: btw, are you writing to stimulus port 0?

11:11 <frankplow> PaulFertser: Yeah stimulus port 0

11:18 <PaulFertser> frankplow: look what I found https://github.com/orbcode/orbuculum/blob/main/Support/gdbtrace.init#L945

11:19 <PaulFertser> frankplow: NRF_P0_PIN_CNF manipulations is something target-specific and not contributed to OpenOCD yet.

11:23 <frankplow> PaulFertser: This looks strange to me. NRF_P0_PIN_CNF is the register for configuring pin P0.00, however SWO is only bound to P0.18

11:30 <frankplow> PaulFertser: So they are using that as a base address to configure P0.18 and P0.20 as outputs here: https://github.com/orbcode/orbuculum/blob/09a612d8fae23b0b5e5940aaac885fb5a7657616/Support/gdbtrace.init#L989-L992 for SWO. Not quite sure what P0.20 has to do with anything here, but I've just tried initialising that as an output as well as P0.18 but no luck.

11:35 <PaulFertser> frankplow: you can try just running that gdb script verbatim who knows, probably it's a bit more tricky than that

11:36 <PaulFertser> I see there's also target-specific NRF_CLOCK there.

12:33 <frankplow> I think I have resolved the issue. Adding `itm port 0 on` seems to have fixed the problem. I did not have this previously as the documentation says "Port 0 is enabled on target creation automatically"

12:36 <zapb_> frankplow, there is only a green LED on the board, right? A flashing green LED usually does not mean a fatal error

12:36 <PaulFertser> Hm, weird, probably that changed.

12:37 <PaulFertser> When I added that code port 0 was enabled by default, but probably it's not the case now.

12:37 <PaulFertser> Guess karlp knows

12:38 <frankplow> zapb_: This is from the J-Link user guide I linked earlier: "GREEN, flashing at 1 Hz: Emulator has a fatal error. This should not normally happen."

12:38 <PaulFertser> frankplow: so did you need any additional code in firmware or mrw commands?

12:41 <frankplow> PaulFertser: Just one thing: 1 (Serial) must be written to the TRACEMUX field of the TRACECONFIG register, see https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/clock.html#register.TRACECONFIG

12:41 <frankplow> The pin does not seem to need to be set up as an output, and I'm not sure why orbuculum is fiddling with P0.20 at all

12:52 <PaulFertser> frankplow: hm, so that should be included in openocd config then I guess

13:03 <frankplow> PaulFertser: I'm not sure what the precendent/convention is for OpenOCD and these things --- whether OpenOCD attempts to set up the entire SWV or just the TPIU. I think it would be okay for OpenOCD to not configure this as it is pretty evident from the MCU's datasheet that it must be set to enable SWO. It was the ITM stimulus port documentation that really caught me out.

13:03 <frankplow> PaulFertser: Thanks a lot for all your help

13:44 <PaulFertser> frankplow: sorry about this problem with the docs, somehow it was changed but the docs were forgotten

13:45 <PaulFertser> frankplow: if you check e.g. target/stm32f1x.cfg you see _proc_pre_enable_$_CHIPNAME.tpiu . The current OpenOCD convention is that everything target-specific to get SWO working should be set up automatically.

17:30 <zapb_> frankplow, I know but from my experience this does not apply to some on-board J-Link probes

18:17 <karlp> no idea. I always felt that blindly enabling port 0 was... "magic" and not the good sort, but it was compatible? I've done very little / zero tracing since the entire config were upended, barely enough to get a few fixes in that broke compat.

18:18 <karlp> I would concur though, that openocd configs should set this up as per requested config...

18:47 <frankplow> PaulFertser: No need to apologise --- thank you for the tool!

18:50 <frankplow> Been looking at putting together a patch for setting TRACECONFIG.TRACEMUX as part of a proc_pre_enable, however unfortunately this register does not appear to be common across the entire nRF52 line. I think this means setting this automatically would require splitting the nRF52 series into seperate targets.

18:53 <PaulFertser> frankplow: or probably it can be detected by reading flash id register or something? Tcl is flexible enough.

18:55 <frankplow> PaulFertser: Ok, I will investigate further when I have some time

18:56 <PaulFertser> frankplow: thank you!

18:56 <PaulFertser> karlp: I wonder when it happened so that itm port 0 is no longer enabled automatically.

19:06 <PaulFertser> frankplow: hm, https://review.openocd.org/gitweb?p=openocd.git;a=blob;f=src/target/armv7m.c;h=d508af7bf0c18d47b52a136c0f09427bc36c73d7;hb=HEAD#l867 it's still there

19:07 <PaulFertser> I guess because it's checking trace_config.itm_deferred_config now.

19:09 <PaulFertser> borneoa___: hey :) can you please take a look at f9509c92dba370be363f5641d3fefe2250bee10c ? Seems like now itm stimulus port 0 is not enabled by default. So either the docs need to be fixed or this deferred init amended.