Debugging code (breakpoints) with reading a FIFO

[tjaekel]

Is my assumption right?

When you have code like this:

 

*(hospi->pBuffPtr - 1) = SPI3->RXDR;

 

and you set a breakpoint on this line (so that is stops before this instruction is executed),

but you have the SFR page open, to see the registers of the peripheral device, here SPI3, including the content of "register" RXDR (which is a FIFO!):

it "will" go wrong?

What could (seems to) happen:

• the open SFR page reads also the register RXDR
• but this is a FIFO!
• so, the debugger view "grabs" the data from the FIFO (and it looks correct what you see as data there)
• and when you continue: you do not get the same value from this register (FIFO): it was read already read (and removed from the FIFO) - your variable assignment "goes wrong"

So, my conclusion would be:

• if you have code where it reads from a FIFO
• set the breakpoint ONLY after the read instruction (not before or at the instruction reading "also" from this FIFO register)

Assume, that a debugger view (SFR page open and displaying the content of also of a FIFO register) will affect the behavior of the code if you keep going ("continue" or "next step": you will potentially not see the data in the variable).
FIFO registers involved can be "tricky" for debugging (using breakpoints and single step).

Is this right?

[tjaekel]

BTW:
it can go also wrong if you check the FIFO status, e.g.:

while ( ! __HAL_SPI_GET_FLAG(&hspi3, SPI_FLAG_RXP)) {;}
*(hospi->pBuffPtr - 1) = SPI3->RXDR;

If SFR page is open, it grabs the FIFO word - you are "out of sync": you will wait for data received (and available in FIFO), but the debugger has "emptied" already the FIFO: you will wait endlessly (nothing comes anymore, already consumed).

Be careful when debugging code when a register read is from a FIFO: the debugger view can "kill" the behavior of your code.

It is not a bug in your FW on in HW: it is caused by the nature of having FIFOs (and a debugger view open affecting the content of a FIFO).

[Tesla DeLorean]

The debugger doesn't have a magic portal to what's in the registers. It uses the same mechanics as you reading in your code.

They are not memory cells, you'll just ratchet the state machine every time you look into the box. The cat will die..

[Pavel A.]

> It is not a bug in your FW on in HW: it is caused by the nature of having FIFOs 

Yes. As they used to say before political correctness was invented: the bug is between the chair and the keyboard : )

 

[AScha.3]

see:

4.Debugging is intrusive

http://www.efton.sk/STM32/gotcha/g4.html

[tjaekel]

Thank you.

"Asking a question can be helpful for other people."

Yes, I am fine with it and aware of it since my "childhood" - LOL.