I've noticed that my watch windows were showing strange data after hitting a breakpoint. Single stepping or setting the PC to the exact same line would somehow "update" to the correct information. Looking at the J-Link logs shows the exact same address being read the second time, only different data is returned!
Here's a scenario:
Let's say you have a pointer-- char *pStuff in ram (0x80000000) and it points to something VALID. What happens is that after hitting a breakpoint the debugger reads the data and you see that read in the log:
Read 4 bytes @ address 0x80000000(Data = 0x000519B7)
Humm. That pointer is bad. (to make matters worse, if you happen to be dereferencing it in the watch window it's game over for your debug session as the CPU vectors into the general exception vector due to an exception in the debugger )
If you single step, the SAME READ OCCURS and different data is returned:
Read 4 bytes @ address 0x80000000(Data = 0x80022538 )
Now that's correct (in my case). This has been happening off and on for a year now and has gradually gotten to the point where it's nearly impossible to debug. Not sure why reads from the same address return different information. I did try throttling down from 12khz to a few khz but that didn't help.
Using Microchip's RealICE on the same port seems to not have the same issue. (This is with the 3 wire PIC programming port)
One last point - I have been tolerating this as an occasional bug but since I've upgraded firmware to 5.02 it now happens constantly. I could simply work around it by typing in the variables I need in the watch window and setting PC to the current location to "update" but that doesn't work given the other issue that hasn't been fixed ( bad addresses make the CPU vector into an exception).
I have been fighting my tools probably more than actual development time. Help! Segger!
Here's a scenario:
Let's say you have a pointer-- char *pStuff in ram (0x80000000) and it points to something VALID. What happens is that after hitting a breakpoint the debugger reads the data and you see that read in the log:
Read 4 bytes @ address 0x80000000(Data = 0x000519B7)
Humm. That pointer is bad. (to make matters worse, if you happen to be dereferencing it in the watch window it's game over for your debug session as the CPU vectors into the general exception vector due to an exception in the debugger )
If you single step, the SAME READ OCCURS and different data is returned:
Read 4 bytes @ address 0x80000000(Data = 0x80022538 )
Now that's correct (in my case). This has been happening off and on for a year now and has gradually gotten to the point where it's nearly impossible to debug. Not sure why reads from the same address return different information. I did try throttling down from 12khz to a few khz but that didn't help.
Using Microchip's RealICE on the same port seems to not have the same issue. (This is with the 3 wire PIC programming port)
One last point - I have been tolerating this as an occasional bug but since I've upgraded firmware to 5.02 it now happens constantly. I could simply work around it by typing in the variables I need in the watch window and setting PC to the current location to "update" but that doesn't work given the other issue that hasn't been fixed ( bad addresses make the CPU vector into an exception).
I have been fighting my tools probably more than actual development time. Help! Segger!
The post was edited 1 time, last by Tj256 ().