is it possible to watch the "write-only" bits in the debug mode?

[JSmit.19]

I am using an STM32L4 MCU and IAR Embedded Workbench. I noted that when I start a debug session in the register window the "write-only" bits of a certain register are field with the letter "w" (for example in GPIOx_BSRR). I was wondering if this is the behavior just in the IAR debugger or it happens for other debuggers as well and is there a way to watch these bits in particular when they are written or not.

[waclawek.jan]

JW

[JSmit.19]

Thanks but I have already read that! that should be clear from the question and answers.

The question is: when these bits are "written" is there a way that the debugger shows a change of state or something like that? Does it depend on the debugger ?

[Uwe Bonnes]

Watchpoints are the way to catch write and/or read to some address. So why do you not use them?

[JSmit.19]

@Uwe Bonnes​ I really said it many times, I don't know if you read my answers or not! I AM using watchpoints ! May I ask what is your debugger and what you get using watchpoints for example for GPIOx_BSRR  which is write-only?

[waclawek.jan]

The debugger, which runs in your PC, communicates with only a very tiny appendix on the ARM processor core, which can use the same bus as the processor (multiplexed in time with the processor) to access the rest of the chip. It also can stop and run the processor if commanded from the PC, and it can also stop the processor if the processor attempts to access addresses matching values in a couple of registers within the debugger. There is literally NOTHING MORE to it.

In other words, the question "can the debugger tell what was written into register ***" is literally the same, as the question "can the processor (can your program) tell what was written into register ***". The only added feature is, that the debugger in the PC can be notified when write into that particular register is attempted, if you have set it so beforehand (that's called watchpoint and that's what Uwe is talking about). Unfortunately, the processor stop happens *after* the write (quite logically so, it's a very simple system, mind), so it's impossible to tell, what value has been written, only the fact, that it has been written.

JW

[JSmit.19]

I think we are going somewhere! Thanks @Community member​ , I really found your answer useful.

you said:

"The only added feature is, that the debugger in the PC can be notified when write into that particular register is attempted, if you have set it so beforehand"

This is exactly my point and what I am looking for!

I am interested in getting a notification by the debugger when a write into these registers happens! but I am NOT getting it!

AGAIN I AM USING WATCHPOINTS! AND I DO SET IT BEFOREHAND (I even have tried live watch), the debugger DOES NOT give me any notification!

At this point, it seems to me that your debugger does notify you and Uwe because you keep mentioning watchpoints!

I asked Uwe twice but he has not answered yet.

May I ask you the same question? Could you please tell me what is your debugger and how this NOTIFICATION looks like in the debug window USING watchpoints for you?

[waclawek.jan]

> what is your debugger

gdb

(that nasty command-line thing)

> how this NOTIFICATION looks like

The processor stops, and I am told of the reason of that stop.

(As I wrote, the value written is already out of the processor so it can't be directly retrieved.)

So, it looks like this:

(gdb) watch GPIOA->BSRR
Hardware watchpoint 2: GPIOA->BSRR
(gdb) c
Continuing.
 
Program received signal SIGTRAP, Trace/breakpoint trap.
HandleModem () at master.c:2327
2327            SYSTICK_START_TIME(modemT);
(gdb)

(gdb) is prompt, and the line after it is what I type; the remaining lines is what gdb writes out. "watch" is the command by which I insert the watchpoint, I enter it while the processor is stopped; "c" is for "continue", telling the processor to run, and then it stops autonomously, writes out the reason for stop ("SIGTRAP", yes gdb can be very vague as it covers a huge amount of vastly different architectures) and writes the line where it stopped. Note, that this line is *after* the BSRR write - in my source file named master.c, line 2326 is a closing bracket and line 2325 contains         PIN_SET(MODEM_POWER_ON);

which is my macro containig the write to GPIOA->BSRR.

JW

[JSmit.19]

@Community member​ Thank you so much! also thank @Uwe Bonnes​ 

I found the problem. It seems it's related to how watchpoints are implemented in IAR Embedded Workbench IDE, there two features:

• Watch
• Breakpoints

"Watch" seems to just observe a variable/address but when a change happens it does not break or stop the processor! it justs updates the value in the GUI if you stop the processor by another mean (using a breakpoint for example) or without stopping if you use a "live watch". (So they do not work for write-only bits)

On the other, there is a certain type of breakpoint called "Data Breakpoint" (which is not very straightforward to find and use!) that does the job of a "watchpoint" (breaks upon a change), so this is to be used.

This was very IAR specific, it's a pity that these features are not well documented and IAR does not have a community, At the end of the day, it's a very powerful toolchain.

Thanks again

[waclawek.jan]

There is no fixed terminology in the field.

> "Data Breakpoint"

It's probably a more often used name for this feature throughout various IDEs than "watchpoint".

It's genuinely hard to construct a tool of such scope as these IDEs have, while maintaining easy and simple access to all possible functions and even have all of them "intuitive".

JW

[JSmit.19]

You're right, indeed they are also called data breakpoints

https://developer.arm.com/documentation/dui0446/z/controlling-target-execution/overview--breakpoints-and-watchpoints#:~:text=A%20watchpoint%20is%20similar%20to,that%20they%20are%20data%20dependent.