Closed protobits closed 3 years ago
If it helps, I find that step by instruction I see that at this point a5 contains 0x40021000 as expected:
But stepping one instruction again makes a5 go to zero, instead of 0x40021004. So I'm not sure what is happening.
It's not obvious to me exactly what you did. The arrow in your screenshot points to a point in the code before regval actually gets the new value.
Are you using step/stepi?
Best is probably to include the gdb session with the commands you ran that gave the confusing result.
Hi, sorry, this was long time ago and cannot reproduce it right now. But from my testing at the time I found that it happened with one gdb but not other from different toolchain. I think that the latest version from SiFive was working but not other ones. As I needed a python-capable gdb and the latest one had an issue (reported here https://github.com/sifive/freedom-tools/issues/71) I couldn't continue testing.
It's not obvious to me exactly what you did. The arrow in your screenshot points to a point in the code before regval actually gets the new value.
Are you using step/stepi?
Best is probably to include the gdb session with the commands you ran that gave the confusing result.
Yes, as I mentioned, at that point the register was OK, but one instruction later (executing the addi) made the register value incorrect.
Could this issue be relevant here I wonder?
https://github.com/riscv/riscv-openocd/issues/559
As mentioned in that issue there are many places where openocd could potentially corrupt registers.
That sounds possible. Given that the problem no longer reproduces, I'm inclined to close this issue. Thoughts?
Sure, thanks
I'm getting strange results when stepping through code with GD32VF103. I have a code that reads a register (RCU_CFG0) and the next line has an
if
over that value. If I place the breakpoint on the assignment and step once, the value of the register is not zero as it should be from reset. However, I can see that reading the register via gdb retrieves a zero value at that point. If I place a second breakpoint on theif
andcontinue
right after the first breakpoint is reached, the variable now holds a zero value. So it would appear that single-stepping from a breakpoint somehow affects reading from memory.Maybe this was what this user was referring to: https://github.com/riscv/riscv-openocd/pull/518#issuecomment-691710695 Are there any known issues with this chip or any errata? (there's at least already one regarding reset apparently)