NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
Willy-- has joined #openocd
<Willy--> Has anyone has issues with building openocd on Ubuntu24? I keep getting a "jimtcl is required" error when running ./configure. I have no issues building on Ubuntu 22 and debian. Google has not been any help in fixing the issue
<zapb_> Willy--, are you sure you're testing the same OpenOCD version?
<zapb_> Willy--, we recently removed the jimtcl submodule from OpenOCD
<zapb_> If it is the same version then maybe the installed jimtcl is not sufficient?
<zapb_> Can you provide more info?
<Willy--> zapb_: I am using the version at https://github.com/openocd-org/openocd.git
<NishanthMenon> Solved with:
<NishanthMenon> sudo apt-get install libjim-dev
<NishanthMenon> at least on my system. just make sure your install has that package (might not be the ubuntu version.. just packages installed)
<Willy--> NishanthMenon: thanks, that worked
<NishanthMenon> cool. ye joineth the line of engineers who hast fallen for the surprise :P (that includes me)
<Willy--> magnificent!
<gamiee> there were some changes lately about jimtcl
<zapb_> NishanthMenon, thanks!
<zapb_> Willy--, nice to see that it works now
<zapb_> NishanthMenon, also nice to see that you now hang around here ;)
<NishanthMenon> ;) i just lurk :D
<karlp> does anyone know why we have stm32u5 support and c0 support, but somehow tarek never got the h5 support upstream? it's in teh st fork since april 2023?
<karlp> I don't see anything on gerrit eitehr
<zapb_> karlp, what fork?
<PlasmaHH> PaulFertser: today I finally found the time to rebase it, clean it up and try it out and in a weird turn of events it worked the first time and could connect to my efm32... so since I want to do that on company time I might try to get it pushed this week...
<PaulFertser> PlasmaHH: wow cool! :)
<PlasmaHH> I have to figure out how to test it further, that is real debugging, loading firmware etc. but I have so many troubles with openocd at other places, and then some of our company hardware not working that its not easy to figure out ...
<PlasmaHH> like, could not get breakpoints to work with ftdi ft2232h chip on efm32gg11 ...
<PlasmaHH> our product that is runnig an stm32h7 cannot be used with the tigard adapter based on that chip...
<PlasmaHH> for whatever reason from one day to the other the ci/cd using tigard on an stm32u5 product stopped being able to flash it (the flashing program hardfaults and I had no time even thinking about debugging it)
<PaulFertser> There shouldn't be anything specific to the ftdi chips though, OpenOCD treats all the adapters the same.
<PlasmaHH> so far I tried only jlinks with the efm32 which works fine but I think they have their special sauce
<PlasmaHH> need to beat out^H^H^H^H^H^H^Hget the stlink back from a coworker to try that
<PaulFertser> jlinks with OpenOCD?
<PlasmaHH> yeah funny combo
<PaulFertser> Hm, there's no special sauce there, both just bitbang JTAG...
<PaulFertser> I mean when OpenOCD is driving a jlink it's usually something very similar to MPSSE.
<PlasmaHH> so it doesnt use any of their proprietary magic?
<PlasmaHH> like, you can send them some cmds over usb to do some stuff on jtag/swd which would in the mpsse/bitbang way need quite a bit of back and forth
<PlasmaHH> never looked into how libjaylink works though
<PaulFertser> OpenOCD isn't using it as a high-level adapter, no.
<PlasmaHH> even more weird what happens there then
<PaulFertser> If you're sure about signal integrity in ftdi case, yes, weird.
<PlasmaHH> not totally, no, but I can attach, read data and registers just fine, just no breakpoints working... and also I am not really sure how to debug that.. I could read the data with an LA and have a look at it but would have no idea at all what I am looking at ;)
<PlasmaHH> funny sidenote: I discovered while trying out the ft232r driver that one of my ftdi chips was a fake one, it wouldnt want to work with our devices while the genuine ones did
<PaulFertser> Breakpoints are implemented by just writing to Flash Patch Breakpoint unit memory-mapped registers so if that kind of communication works breakpoints should work too.
<PlasmaHH> I dont know if that chip has them, there is also some debug registers for 4 or so breakpoints I think?
<PlasmaHH> might set a breakpoint and expect all of that ...
<PlasmaHH> I really should probably implement my register saving idea so I can use the single step register comparison for all peripheral registers to see whats going on and changing...
<PlasmaHH> https://github.com/PlasmaHH/vdb/raw/master/doc/img/xi.0.png imagine the time it takes to do comparison of all peripheral registers for each single step ^^ https://github.com/PlasmaHH/vdb/raw/master/doc/img/xi.0.png
<PaulFertser> That's the thing that's shown after the target is examined, the number of hw breakpoints and watchpoints.
<PlasmaHH> ok, will have a look
<PlasmaHH> pro tip: don't use the user button on nucleo boards to trigger swo output for testing it when you use the 32khz oscillator
<zapb_> karlp, maybe not ready/clean for upstream?
<zapb_> And no time for cleanup
<PlasmaHH> hm, just noticed there is no special loader for u5 ... which one will be used the instead?
zjason``` has joined #openocd
zjason`` has quit [Ping timeout: 272 seconds]
pengi33 has quit [Ping timeout: 248 seconds]
pengi33 has joined #openocd
<karlp> zapb_: yeah, not sure, someone mentioned it elsewhere, they were usings omethign else because of h5 support, and it just seems odd, they submit everything else, but h5 somehow just... hasn't come in for some reason.