04:36 <harryballs> Hey all

11:11 <karlp> I'm trying to use a watchpoint on cortex-m0, and I'm hitting "watchpoint value masks not supported"

11:11 <karlp> but I don't want or need a mask,

11:11 <karlp> I'm just doing "watch blah" in gdb

11:12 <karlp> and help watch doesn't show anything about masks.

11:14 <karlp> the gdb remote reports it got "@bar(input):button2

11:14 <karlp> fack

11:14 <karlp> not that

11:14 <karlp> Z2,4002e024,4

11:17 <karlp> which _looks_ like "just watch the 32bit word at 4002e024" which is what I want.

11:17 <karlp> (I'd also tried watch *0x4002e024 but get the same errors)

11:20 <karlp> ok. umm. this looks like a weird 32/64bit issue?

11:23 <karlp> https://github.com/openocd-org/openocd/blob/master/src/target/breakpoints.h#L39 is defined as a 64bit 0xfffffff...

11:23 <karlp> and struct watchpoint has a 64bit mask value

11:24 <karlp> but when I arrive into

11:24 <karlp> cortex_m_add_watchpoint

11:24 <karlp> I have a 32bit mask 0x 0xffffffff, as would be apppropriate for my target...

11:25 <karlp> damnit, watchpoint_add has the 64bit mask.

11:27 <karlp> watchpoint_add_internal throws it away and uses 32bit mask?!

11:30 <karlp> it's a regression :) yay.

11:30 <karlp> let me test this out...

11:35 <karlp> yay works again.

11:37 <karlp> I mean, it hasn't helped me catch who writes a zero to my peripheral, but I guess that's because it's clocked/unclocked, not _written_ I guess.

11:37 <karlp> ok, let's get this patch up

11:45 <karlp> https://review.openocd.org/c/openocd/+/8364 why didn't that pick up the "fixes: " tag?

11:52 <karlp> borneoa___: if you're still "just about" to make 0.13, I'd say that regression is pretty important to pull in. fortunately it came in after 0.12

12:01 <karlp> ffs, it's already submitted, if I'd read all the footnotes on the original one

13:56 <indy-> hi all, is there any patch for using latest jimtcl in openocd? in fedora i get in rawhide failures with jimtcl-0.83

14:50 <borneoa___> karlp: no schedule for 0.13, yet

14:52 <borneoa___> indy: Humm, jimtcl 0.83 tagged August 28. We all missed it! Must be addressed asap and that's a good reason for a new tag, probably a minor release

14:54 <borneoa___> indy: if you can, please send more info on the mailing list or open a ticket, so everyone gets aware of the details

14:57 <karlp> borneoa___: no stress then :)

14:58 <karlp> but yeah, watchpoints are pretty busted right now. I believe they'll only work if you specify a mask, and your hardware supports masking, and the masks are less than 32bits.

14:58 <karlp> plain "watch var" is börked.

14:58 <Haohmaru> björked.

15:25 <slobodan> Hey folks

15:26 <slobodan> https://i.ibb.co/yggs2gM/almost-done.jpg

15:27 <slobodan> Uh wrong channel again sorry :)

16:53 <bacam> a

17:00 <bacam> Oops

19:09 <zapb__> karlp, oups, good watch. let me try to very this here... do you have a minimum working example?

20:47 <borneoa___> indy: please have a look at Gerrit patch 8512. Compile is fixed, but I have not tested if jimtcl 0.83 introduces some runtime regression

20:48 <borneoa___> PaulFertser: should we consider commit 8512 for a 0.12.1 ? After some tests, of course

20:59 <PaulFertser> borneoa___: s/than need it/that need it/ . Hm, why not. If 0.13.0 is still too far away the distro maintainers might benefit from that point release, yes.

21:04 <borneoa___> PaulFertser: thanks for the review! Updated! I cannot imagine any regression from that patch, but I want some extra check on the new jimtcl. The patch alone gives the incorrect feeling that jimtcl 0.83 is fully ok with OpenOCD

21:05 <PaulFertser> Good point! It's C so if it compiles doesn't mean it works.

21:43 <borneoa___> PaulFertser: more complex then expected. v0.12.0 requires backporting 7405, 7517, 7721 and 8512 ! Then it will compile for jimtcl 0.83 (and older from 0.79)

21:46 <PaulFertser> BTW, trying to use SWO capture on stlinkv2 from a nucleo board and if I power off the target while openocd is running then I'm not ever getting SWO back (by restarting OpenOCD) until power cycling the stlink it seems.

21:47 <PaulFertser> I haven't tried understanding or debugging it yet, sorry.

23:09 <karlp> zapb__: "watch var" will fail?

23:10 <karlp> well, it will accept, until you do a "run" or continune or anyting and it tries to actualyl insert it.