14:33 <sys64738> re: SAML11: looks like using a jlink mini instead of an FT4232 does make connecting to the CPU work, though flashing doesn't work (openocd fails at resetting the CPU, apparently). using the jlink software does make everything work. so in any case, there is *something* not working properly in openocd's support for the SAML11

14:34 <sys64738> (same result again across 0.11.0, 0.12.0, and git commit edf2c82cf)

14:36 <Haohmaru> i think afaik jlink has some fancy software inside which is aware of different kinds of target chips and probably does some things

14:36 <sys64738> yeah that sounds likely

14:38 <Haohmaru> there were some segger debuggers which include everything up to a complete gdb server

14:38 <Haohmaru> for that to work, they'd have to deal with the chip-specific crap in the debugger itself

14:39 <sys64738> yeah, I'm aware (blackmagic debugger is the name of that one)

14:39 <sys64738> (and forks of it like farpatch)

14:40 <sys64738> but that one doesn't have any SAML1x support at all so doesn't help me atm

14:40 <Haohmaru> iirc the blackmagic thing wasn't from segger

15:05 <sys64738> ah yeah that's correct

16:52 <PaulFertser> sys64738: no, jlink is used in exactly the same way as ftdi mpsse with OpenOCD, nothing fancy.

16:53 <PaulFertser> I mean jlink with OpenOCD of course.

16:59 <zapb__> sys64738, there is a "high-level interface" for J-Link probes but that's not used by OpenOCD

18:27 <sys64738> well in any case, this is what I'm observing

18:37 <zapb__> sys64738, are you using a dev board? I assume JLinkCommander uses a different reset strategy or something like that

18:38 <sys64738> I'm using https://rtfm.newae.com/Targets/UFO%20Targets/CW308T-ATSAML11/ , which isn't *quite* a devboard as you have to bring your own debugger thingy

18:38 <sys64738> (see also the scrollback from last thursday? friday?)

18:38 <sys64738> ah wait no, tue 08 oct even

20:04 <zapb__> sys64738, okay... 404 but I'm quite familiar with this HW ;)

20:22 <sys64738> 404 what? that link works for me

20:22 <PlasmaHH> Hi, anyone familiar with swo/itm output of stm32u5 ? I don't quite get what the -formatter parameter is for in the tpiu command for enabling swo data...

20:25 <PaulFertser> PlasmaHH: hi.

20:25 <PlasmaHH> my problem is that with "on" the data over the wire is broken but with "off" while it is right, I dont get anything at the output tcp port

20:26 <PaulFertser> PlasmaHH: the thing is that ITM data goes through TPIU where it can be mixed (or not) with tracing data from ETM. And unless you need that tracing you should disable formatter because it doesn't help.

20:27 <PlasmaHH> PaulFertser: ah I see... while that doesnt explain why in that case the data is broken ( I dont have anything tracing enabled I think ) there is now still the problem of openocd not forwarding that data to me

20:27 <PaulFertser> PlasmaHH: so how do you configure that tcp port then?

20:28 <zapb__> sys64738, I get an error 404 here, anyway ... maybe I find some time to test the target

20:28 <PlasmaHH> PaulFertser: the important config line is: stm32u5x.tpiu configure -protocol uart -pin-freq 20000000 -traceclk 160000000 -output :22888 -formatter off

20:28 <PaulFertser> PlasmaHH: how do you check brokenness? Probably the tool just doesn't expect formatted data?

20:28 <PaulFertser> PlasmaHH: and btw what are you capturing with?

20:29 <PlasmaHH> PaulFertser: I looked at the data with a logic analyzer with -formatter on and I could see that it was often not sending what I put into ITM_SendChar

20:29 <PlasmaHH> PaulFertser: I am using an stm32u5a5 nucleo board with the onboard stlink

20:30 <PlasmaHH> so -formatter off it is, now I just need to get openocd to output me some data

20:30 <PaulFertser> PlasmaHH: can that stlink capture at 20 MHz?

20:31 <PlasmaHH> PaulFertser: now that is a good question, lets see

20:31 <PlasmaHH> (only so far confirmed with the logic analyzer that the data is correct on the pin )

20:31 <PaulFertser> PlasmaHH: I think you should just omit -pin-freq altogether if you're using stlink to capture.

20:33 <PlasmaHH> PaulFertser: unfortunately that gives me Error: SWO frequency is not suitable. Please choose a different frequency. ... probably because it tries to use a default frequency of 24mhz or so?

20:33 <PlasmaHH> using 2mhz works so it most likely is that it cannot capture at 20mhz

20:34 <PlasmaHH> hm, openocd says it doesnt support higher than 24mhz but already at 20mhz it stops outputting stuff... 16mhz works fine so I guess I settle for that now

20:36 <PlasmaHH> finally I can start writing my swo plugin ^^

20:36 <PlasmaHH> thanks a lot that was bugging me for weeks

20:37 <zapb__> PlasmaHH, what kind of plugin?

20:37 <PaulFertser> PlasmaHH: probably it's a signal integrity issue in your case.

20:37 <PaulFertser> PlasmaHH: stlinkv3 should be able to capture up to 24 MHz, yes. Probably you need to add some kind of termination there or more ground connections between the target and adapter?

20:40 <PlasmaHH> zapb__: for gdb, all kinds of functionality I need

20:40 <PlasmaHH> PaulFertser: its built into the nucleo board, I would hope for them to have the best connection possible. Also my logic analyzer with flimsy wiring can capture it just fine at those speeds... doesn't matter right now, 16mhz is fine

20:41 <zapb__> PlasmaHH, like a decoder or what functionality?

20:42 <PlasmaHH> zapb__: yes for swo I plan on writing a decoder that is aware of the different streams so within gdb I can output them to different targets if necessary ( my gdb plugin provides the ability to redirect output to other ttys or tcp ports or so ). plus I want to send it through rich for colouor support ;)

20:46 <zapb__> PlasmaHH, you should consider to use one of the already existing libraries

20:46 <PlasmaHH> zapb__: well maybe, do you know any good swo decoding one?

20:48 <zapb__> PlasmaHH, https://github.com/orbcode

20:48 <zapb__> PlasmaHH, https://gitlab.zapb.de/zapb/libswo

20:48 <zapb__> there are probably more

20:49 <PlasmaHH> zapb__: I would prefer a pure python solution

20:49 <zapb__> PlasmaHH, I see, then I don't know but probably there is already one :D

20:50 <PlasmaHH> zapb__: when I had a quick look all I could find was a simple script that decodes and outputs...

20:50 <PlasmaHH> the protocol isn't too hard to decode though

20:58 <PlasmaHH> FirstI think I need to implement me some advanced register blacklisting feature, its not a good idea to try reading the tpiu registers when no tpiu stuff is enabled...