09:23 <PlasmaHH> is there any setting or so that when openocd cannot read some memory it will tell gdb instead of returning 0 ? with other debuggers and on the host I get nice errors for these cases...

09:24 <PaulFertser> PlasmaHH: hm, are you sure it's returning 0 ?

09:24 <PaulFertser> PlasmaHH: it's not normal, please use some pastebin to show the logs.

09:26 <PlasmaHH> PaulFertser: absolutely ... x on any address thats not mapped or otherwise inaccessible is returning 0

09:27 <PaulFertser> PlasmaHH: on what target?

09:27 <PlasmaHH> PaulFertser: https://paste.opensuse.org/pastes/2deae52d0cf1

09:28 <PaulFertser> PlasmaHH: and what does "mon mdw" for that address say?

09:28 <PlasmaHH> PaulFertser: Failed to read memory at 0x05536364\nProtocol error with Rcmd

09:29 <PaulFertser> PlasmaHH: hm, odd, so can you do "set debug remote 1" and re-run "x" for that address and show both what GDB and what OpenOCD says?

09:31 <PlasmaHH> PaulFertser: https://paste.opensuse.org/pastes/f2a037c6d309

09:32 <PlasmaHH> PaulFertser: is there a possibility that the support for this particular stlink debugger is at fault? I am using a patch from ST for it

09:32 <PaulFertser> PlasmaHH: damn that's nasty indeed, thank you for reporting.

09:32 <PlasmaHH> openocd only says Failed to read memory, I guess I would need some debug settings for it too?

09:33 <PaulFertser> PlasmaHH: no, looks not adapter specific at all.

09:33 <PaulFertser> PlasmaHH: you can run "openocd -d3", yes, that alone would show everything that's of interest properly.

09:33 <PlasmaHH> in case its intresting, I have git commit eebcf3cff plus that st patch

09:34 <PlasmaHH> PaulFertser: https://paste.opensuse.org/pastes/45896a0a6521 for the x command

09:34 <PaulFertser> PlasmaHH: the last one is perfect

09:35 <PaulFertser> PlasmaHH: do you feel like creating a bug report on SF.net so that it's not forgotten?

09:36 <PlasmaHH> sure, you don't happen to have direct link to the project page? ;)

09:37 <PaulFertser> PlasmaHH: https://sourceforge.net/p/openocd/tickets/

09:37 <PaulFertser> :)

09:38 <PlasmaHH> ( I am not going through a rant on how the content proxy at the company somehow blocked the search )

09:44 <PlasmaHH> PaulFertser: https://sourceforge.net/p/openocd/tickets/406/ hope that has everything necessary

09:44 <PaulFertser> PlasmaHH: thank you!

09:45 <PlasmaHH> this problem is extremely annoying because I usually have a mechanism in place in my gdb plugin that automatically creates me a blacklist for memory that is not accessible, mostly because there are some peripherals that you cannot read, otherwise the chip locks up

09:45 <PaulFertser> Sure thing!

09:48 <PaulFertser> PlasmaHH: oh shit, there's an undocumented command to fix the behaviour: gdb_report_data_abort

09:48 <PaulFertser> Documented command.

09:48 <PaulFertser> PlasmaHH: so do "gdb_report_data_abort enable"

09:49 <PlasmaHH> PaulFertser: arguably that should be the default behaviour

09:50 <PaulFertser> PlasmaHH: yeah, if you can try stack traces with that enabled; probably it was meaningful only back in 2008.

09:51 <PaulFertser> PlasmaHH: once you try doing everything you normally do, and stack traces and probably stack traces from inside ISR handlers, and everything works, please just add to the ticket that the default behaviour should be flipped.

09:51 <PlasmaHH> PaulFertser: no problems with stack traces with that enabled... I also can't think of a case where it would be a problem ...

09:52 <PlasmaHH> in all the months with this project now I have never encountered any problem with the jtrace probe which reports that back to gdb, so if must be rather rare I guess

09:54 <PaulFertser> PlasmaHH: guess was fixed since 2008, yes.

09:56 <PaulFertser> It should have been tracked by https://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=2395

09:57 <PlasmaHH> PaulFertser: getting an internal server error for that one from here... sigh

09:58 <PaulFertser> PlasmaHH: hence my wording

10:01 <PlasmaHH> now the one other thing that would really round off my detection code is if there was a way openocd notifies me within gdb about when the connection to the chip is lost...

10:11 <PaulFertser> PlasmaHH: does that work with jlink gdb server?

10:12 <PlasmaHH> PaulFertser: no, unfortunately not

10:12 <PlasmaHH> haven't found any that does it, sadly

10:12 <PlasmaHH> Usually you only notice when stuff throws errors all over the place ;)

10:15 <PaulFertser> PlasmaHH: but you want it while the target is halted or running?

10:15 <PaulFertser> OpenOCD doesn't poll halted target.

10:18 <PlasmaHH> PaulFertser: let me get a wider picture... so when I do e.g. x/i 0xe0040000 then I (now) get a failed read, and openocd seems to detect that something is wrong: https://paste.opensuse.org/pastes/1f17cb9fef86

10:20 <PaulFertser> PlasmaHH: yep, probably after a failing read you can check output from "mon targets"? If that doesn't have any indication, I can try to check if there's anything else that can report that target isn't available atm.

10:23 <PlasmaHH> PaulFertser: state changes to unknown... thats not as good as any "event" type direct message to gdb but far better than nothing ( maybe the gdbserver protocol doesn't even have anything, don#t know )

10:24 <PaulFertser> PlasmaHH: so at least you have a workaround now, good.

10:25 <PlasmaHH> PaulFertser: yeah, thanks, nothing is more annoying than lots of stuff suddenly not working and not kowing why.... also hate it when chips lock up just by reading something ;)

10:26 <PaulFertser> Indeed!

10:27 <PlasmaHH> and some debugging tool manufacturers say something along the line of "well, its their fault, tell them to fix it" ... yep, great idea

10:44 <PlasmaHH> now I just need some proper hardware to use the etm trace features and get that somehow into my gdb plugin ;)

10:51 <PaulFertser> PlasmaHH: orbtrace

10:53 <PlasmaHH> PaulFertser: seems like they're out of stock at places where they are sold :/

10:54 <PaulFertser> PlasmaHH: ask zyp on ##stm32 directly

10:55 <PlasmaHH> PaulFertser: oh nice, yea

11:00 <PlasmaHH> PaulFertser: end goal is to have some somewhat convenient way to combine instruction trace and power consumption...

11:03 <PaulFertser> PlasmaHH: would be great to have

11:06 <PlasmaHH> PaulFertser: segger jtrace promises to do that, but besides their current measurement being very noisy, their tooling sucks and their support flips you the bird... stlink brought out a nice thing for current measurement, unfortunately no tracing, but that made me think of maybe combining two dedicated devices for that purpose

23:13 <aisha[m]> hey all, I finally got the wires needed for connecting my orange pi 5 to the jlink but I'm not sure what wires to connect it to, is there anyway to know how to connect to the device by which pins in the gpio?