09:16 <karlp> we don't know, they never really got to anything actionable.

10:17 <phr3ak> when I turn on a watchpoint the processing slowing down (few systicks per second). if I delete this watchpoint everything goes back to normal. in the debug log, i see DWT on and off frequently. Cortex-M3 / Ulink2 with CMSIS-DAP

10:32 <karlp> in what debug log?

10:32 <karlp> do you mean you see openocd turning the watchpoitn on and off repeatedly?

10:33 <karlp> are you setting watchpointswith gdb? it's possible it's not getting translated into a "nice" dwt watchpoint?

10:34 <phr3ak> i don't know what is nice but it does not do with an other variable so if I select other variable to watch

10:35 <phr3ak> I ran openocd with -d

10:36 <phr3ak> and I saw that rapidly repetitive DWT on/off messages there.

10:36 <karlp> what's the variable?

10:36 <karlp> I'm guessing it's somehow not translating into a single dwt entry?

10:36 <karlp> how are you measuing this "few systicks per second" ? (just curious)

10:37 <karlp> I wouldn't hav ethought tht modifying dwt while running should have mattered anyway, but something's intruding I guess.

10:40 <phr3ak> I pressed c, continue, waited a bit, stop, and check a variable that is increased by systick. and there is led blinking in systick ...

10:40 <phr3ak> that's how I found out that the system slowed down

10:41 <phr3ak> if I deleted the watchpoint then it went back to normal

10:42 <phr3ak> then I looked at the debug log, what is the difference if I set watchpoint to the two different variables and I noticed that when the system is slow, a lot of log messages appear...

10:43 <phr3ak> both variables are int

10:47 <karlp> can you share a debug trace of the "good" variable and the "bad" one?

10:47 <karlp> you're obviously seeing a _lot_ of slowdown, if you're seeing it by watching a led blinking.

10:47 <karlp> um. is the watchpoint _hitting_ a lot?

10:49 <phr3ak> i'm connecting the device and reproduce the issue

11:01 <phr3ak> well, so it should

11:01 <phr3ak> sorry

11:01 <phr3ak> so it is not stopping

11:02 <phr3ak> but it should

11:02 <phr3ak> i know this variable is changing in this interrupt handler

11:02 <phr3ak> this is why I wanted to watch

11:03 <phr3ak> but the processing is not stopping while I press ctrl-c in gdb

11:03 <phr3ak> while i'm not pressing ctrl-c

11:11 <phr3ak> DWT0 0x2007d21c 0x2 0x00006

11:11 <phr3ak> is it r/w/x?

11:11 <phr3ak> this DWT is cleared and installed again and again

11:12 <phr3ak> (this code runs in memory)

11:12 <phr3ak> so not from flash

11:13 <phr3ak> i'm checking this address but I think it is the code and not the variable itself

11:14 <phr3ak> this is the variable's address. so it is correct.

11:21 <phr3ak> DWT installed and deleted about 65 events later

11:22 <phr3ak> but gdb does not stop

11:26 <phr3ak> so the problem seems to be that gdb doesn't stop, even though watchpoint gets a hit

11:30 <karlp> please... logs..

11:30 <phr3ak> ok how could I send to you

11:30 <karlp> paste bin of some sort.

11:31 <karlp> include your gdb logs too.

11:46 <phr3ak> https://pastebin.com/UQqY8knc

11:47 <phr3ak> Found hit watchpoint at 0x2007d21c (WPID: 0)

11:47 <phr3ak> but gdb does not stop

11:50 <PaulFertser> Hm, as if GDB gets the information but decides to continue instead of stopping..

11:52 <karlp> info breaks doesn't have an address in it?

11:53 <PaulFertser> What GDB is that? Is that an ARM or multiarch binary? It looks like it's getting confused somehow.

11:53 <PaulFertser> And yes, no address is fishy.

11:53 <phr3ak> GNU gdb (GNU Tools for ARM Embedded Processors (Arduino build)) 7.6.0.20140228-cvs

11:54 <karlp> that's a... _very_ old gdb.

11:55 <PaulFertser> Hah, yes, just use the one provided by your distro, the multiarch version.

12:15 <phr3ak> same with newer gdb

12:15 <phr3ak> it got hit first four times but no more

12:16 <phr3ak> there is no address at info break

12:17 <phr3ak> is it read write or exec DWT breakpoint?

12:18 <phr3ak> it got more hit but the execution is slow

12:19 <PaulFertser> phr3ak: what is the variable type?

12:19 <phr3ak> int

12:22 <PaulFertser> There must be some difference between the times it's hit and GDB is stopped and when it's hit but GDB isn't stopped...

12:24 <phr3ak> what should be the type of DWT breakpoint rwx in case if I create it with watch command?

12:24 <phr3ak> I would say write only

12:25 <phr3ak> but maybe i'm wrong

12:25 <phr3ak> so this is a question

12:30 <phr3ak> the possible reason for not stopping because the value is not changed, the memory location has been written with the same value as it was previously

12:30 <PaulFertser> phr3ak: I think that might be why GDB filters it out, that would kind of explain it.

12:31 <phr3ak> the address is empty at info break. is it ok or bug?

12:32 <PaulFertser> Feels odd.

13:25 <phr3ak> what is the name of the other type of breakpoint that is not DWT?

13:28 <phr3ak> maybe DWT is software breakpoint the other is hardware breakpoint

13:28 <phr3ak> but I'm not sure

13:29 <phr3ak> address is missing at info break if the breakpoint is DWT breakpoint

13:46 <PaulFertser> phr3ak: no, software breakpoints can't be used as watchpoints.

13:46 <PaulFertser> phr3ak: DWT is used for both hardware breakpoints and data watchpoints.

13:46 <PaulFertser> phr3ak: when you're running from RAM OpenOCD can use software _breakpoints_.

14:23 <phr3ak> it's compilated atm i don't really understand. anyways, when I create breakpoint for code and not for data like break function, then I don't see DWT in log so this is why i think it is something different than DWT, and the address is showing up at info break. If I create watchpoint variable then I don't see the address at info break

14:24 <PaulFertser> phr3ak: by default GDB is using software breakpoints for code running from RAM.

14:26 <phr3ak> what is software breakpoint exactly? does it replace the original instruction to an instruction that cause Debug exception?

14:53 <PaulFertser> phr3ak: exactly

14:55 <phr3ak> thanks

14:56 <phr3ak> could i turn on timestamp for openocd logging?

14:57 <PaulFertser> phr3ak: hm, isn't it there by default? Starting from 0, not rtc.

14:57 <PaulFertser> Hm, not in your log.

14:59 <PaulFertser> I think it's there after the log counter.

14:59 <PaulFertser> "Debug: 76 1132 cmsis_dap_usb_bulk.c:126" <--- 1132 is the timestamp phr3ak

15:26 <phr3ak> I'm still investigating why it's slow. I see a big delay here:

15:26 <phr3ak> Debug: 98020 625921 gdb_server.c:406 gdb_log_outgoing_packet(): [sam3.cpu] sending packet: $O#4f

15:26 <phr3ak> Debug: 98021 626423 gdb_server.c:406 gdb_log_outgoing_packet(): [sam3.cpu] sending packet: $O#4f

15:51 <phr3ak> but maybe it is normal

16:15 <phr3ak> so the delta time is around 600ms between two watchpoint hit and in normal condition it should be 1ms interval as it is in the systick

16:41 <karlp> how ar eyou measuring that?

16:42 <karlp> you can configure many timers to stop or not stop when debug stops.

17:00 <phr3ak> grep watchpoint_hit openocd.log

17:06 <phr3ak> small addition the USB connection with ULINK2 is full speed (12M)

17:14 <phr3ak> and it is SWD not JTAG

17:36 <phr3ak> I measure 100ms if I grep stderr ...

17:40 <phr3ak> why does the gdb install and delete watchpoint again and again if that unchanged?

17:49 <PaulFertser> phr3ak: you can do "set debug remote 1" in GDB and show that log to GDB devs on their IRC channel, probably they'll tell you why.

17:50 <phr3ak> thanks I will check it

18:14 <phr3ak> i just tried it with a x64 gdbserver and no repeating commands

18:15 <phr3ak> i can see repeating commands if I add a single watchpoint

18:16 <phr3ak> in case of openocd

21:34 <phr3ak> I looked at what is happening at the remote protocol level and there is lot of unnecesary message exchange. Instead of reading a memory location and continuing execution, it removes and re-add the same breakpoint, reads all registers twice, reads the inspected memory location four times and so on.

21:35 <phr3ak> These redundant and maybe unnecessary message exchanges become more of a problem when one high level, GDB remote protocol request-response message becomes multiple request-respose messages at lower level, causing lot of latency and very slow program execution at the end.

21:37 <phr3ak> these commands are running again and again after one watchpoint hit:

21:37 <phr3ak> https://pastebin.com/JFQpsH4A

21:40 <karlp> you will see some redunancy, but not all of it is going to be related. (there can always be optimizations, but not all of these are problematic for you)