18:20 <MHU123> Hi, anyone here having experience with debuggin an RP2350 (CM33) with openocd + GDB? I've got the problem, that breakpoints I set in GDB with e.g. "b picow_blink_fast_clock.c:26" are not hit.

18:21 <MHU123> I looked at the ROM table of the CM33 and saw that the FP_COMP0... registers are located at 0xE0002008...

18:22 <MHU123> If I manually peak at these addresses using hte telnet port and "mdw 0xe0002008 0x5" I oly see zeroes.

18:23 <MHU123> Once I manually write a breakpoint with "mww 0xe0002008 0x10000249"

18:23 <MHU123> it is hit

18:49 <zapb__> MHU123, there are some patches on Gerrit for RP2350, maybe they help?

18:50 <zapb__> MHU123, if not let me know, I have a target to test. IIRC breakpoints worked

18:53 <MHU123> I found the reason!

18:53 <MHU123> Debug: 4229 30005 cortex_m.c:1667 cortex_m_set_breakpoint(): [rp2350.dap.core0] BPID: 0, Type: 1, Address: 0x10000242 Length: 2 (n=0)

18:53 <MHU123> Type 1 -> according to cortex_m.c this is a "soft" breakpoint

18:54 <MHU123> I had problems witht he flash loader etc and removed it. So oocd is not able to patch in a soft breakpoint

18:54 <MHU123> Adding the option " gdb_breakpoint_override hard" fixes the issue

18:55 <MHU123> Now a hard breakpoint is created that uses the core's breakpoint unit

19:08 <gamiee> MHU123 : when creating breakpoint, use "hb" instead of "b"

19:11 <MHU123> gamiee, Thanks!

19:12 <gamiee> MHU123: by default GDB does not know if it's writable or read-only area. Mostly it presumes it's writable and uses software breakpoint. You can change that with breakpoint override in GDB, use "hb", or marking memory area you want to use as ro through "mem" command

19:13 <gamiee> https://sourceware.org/gdb/current/onlinedocs/gdb.html/Memory-Region-Attributes.html

19:14 <MHU123> Great info! Thanks. the issue is most likely on my side, as I use a rp2350.cfg that had problems with the memory setup and I just commented out all the memory map stuff.

19:17 <gamiee> np :)

23:09 <wrongbaud1> Hey All, I am using a Raspberry Pi 4 as a JTAG adapter and the 6.6 Kernel seems to have broken the bcm2835gpio adapter driver. Does anyone know of any workarounds for this? I was considering using libgpiod but could not find an example for the Pi 4, only a Pi 5

23:12 <wrongbaud1> I've tested the same hardware/config file setup with two different images, one running 6.1 and one running 6.6 and it seems as if the 6.6 is not properly selecting the appropriate pins using the bcm2835 adapter driver.

23:13 <PaulFertser> wrongbaud1: hey

23:14 <PaulFertser> wrongbaud1: is there any error visible?

23:14 <wrongbaud1> Unfortunately not - all I see are bunch of incorrect IDs when using kernel version 6.6

23:15 <PaulFertser> wrongbaud1: hm, probably your other image has some overlay enabled that pinmuxes the pins to different peripherals instead of leaving them as GPIO?

23:16 <PaulFertser> You can test each pin manually if you have a voltmeter while toggling it with "gpioset" utility.

23:16 <wrongbaud1> Unfortunately no :(

23:16 <wrongbaud1> I checked the status using pinctrl and they are all set up as normal GPIO pins, both images are using the same set of DTB overlays

23:16 <PaulFertser> If gpioset works then libgpiod adapter driver will work too, and you do not need any specific example, just specify the pins matching your hardware config.

23:17 <wrongbaud1> Ok - I can give that a try

23:17 <PaulFertser> fwiw, bcm2835gpio directly manipulates GPIO peripheral registers so hm, odd story.

23:18 <wrongbaud1> Yeah I know, that's what is confusing to me

23:18 <wrongbaud1> It is very weird, I wish I had my logic analyzer with me to generate some logs and see what is different, I can definitely do that when I'm home though

23:19 <PaulFertser> Even better would be to use an oscilloscope to be sure about the edges and potential ringing.

23:19 <PaulFertser> I have a toy one for 25 bucks and I still think it's totally worth it.

23:20 <wrongbaud1> I can definitely do that and report back to you all!

23:20 <PaulFertser> wrongbaud1: please do not forget to report your findings here or via the mailing list

23:21 <wrongbaud1> absolutely - I will do that, thank you for responding and for all of the work that you all do

23:21 <PaulFertser> (started typing that before you messaged :) )

23:22 <PaulFertser> wrongbaud1: btw, are you connecting directly to the target? Please keep in mind that maximum drive strength sometimes leads to ringing (depends on the wiring and the target) on any frequency, so usually adapters have at least some series termination on signal lines (like 47 -- 100 Ohm).

23:22 <wrongbaud1> I spent half a day thinking it was bad jumper wires, etc. Then switched to an older kernel version with the same OpenOCD version and everything worked, so I'm very excited to get home with my scope and get some ground truth on what might be going on

23:24 <PaulFertser> But that wouldn't explain what you observe. So yes, will be waiting for your probing results.

23:26 <wrongbaud1> Yeah, it is very strange, same wiring, different kernel versions, one works and one doesn't. I have to hop off here but I will report back sometime next week with more info (it's probably just something stupid that I am doing, but either way I'll report back :D)

23:28 <wrongbaud1> thanks again for the response, I'll chat with yall soon!