Skip to main content
JSmit.19
Associate II
February 2, 2021
Question

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

  • February 2, 2021
  • 11 replies
  • 2844 views

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.

This topic has been closed for replies.

11 replies

waclawek.jan
Super User
February 2, 2021

No, they read as 0.

JW

JSmit.19
JSmit.19Author
Associate II
February 3, 2021

No what?! The debugger cannot read it because it returns 0 you mean? Or it can be read but it leads to 0? Does it depend on the debugger?

Uwe Bonnes
Chief
February 3, 2021

It depends on the exact bit definition as (hopefully) explained in the reference manual. And no, you will not get the state of that bit with any debugger.

JSmit.19
JSmit.19Author
Associate II
February 3, 2021

Thanks, the second part addressed my question. "you will not get the state of that bit with any debugger"

I was kinda hoping that when they are "written" the debugger shows a change of state or something like that.

Uwe Bonnes
Chief
February 3, 2021

You can set a watchpoint on that register address to see when and what is written.

JSmit.19
JSmit.19Author
Associate II
February 3, 2021

That's the point, how? the register window should watch that register itself but it does not show anything when those bits are written, I could try another way to watch them in the debugger but the result should be the same.

Uwe Bonnes
Chief
February 3, 2021

Your debugger should be able to set watchpoints, read the docs. In gdb I type e.g. "watch -l <expression>" . On running gdb at the moment I am not sure if e.g. is "GPIOA_>BSRR" or "&GPIOA_>BSRR"

JSmit.19
JSmit.19Author
Associate II
February 3, 2021

What I meant was the debugger IS indeed watching them, they are different ways to watch though, when I open a register window for GPIOA for example all the registers are shown in that window, I could also set a watchpoint just for a certain register of the GPIOA, that should not change anything, I'll try though.

My point was looking at the register window (again in which the registers should be watched) when I write in a "write-only" bit the debugger does not show any change of state.

JSmit.19
JSmit.19Author
Associate II
February 3, 2021

@Uwe Bonnes​ I tried different ways to watch the BSRR register for all of them the value was "unavailable".

Have you ever watched BSRR or any other  "write-only" bit? What do you see/expect in watch?

waclawek.jan
Super User
February 3, 2021

0693W000007Dr2sQAC.pngJW

JSmit.19
JSmit.19Author
Associate II
February 3, 2021

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
Chief
February 3, 2021

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

waclawek.jan
Super User
February 3, 2021

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
JSmit.19Author
Associate II
February 3, 2021

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
Super User
February 3, 2021

> 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
JSmit.19Author
Associate II
February 4, 2021

@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