Pic32/J-Link reads bad data on breakpoint

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Pic32/J-Link reads bad data on breakpoint

    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!

    ?(

    The post was edited 1 time, last by Tj256 ().

  • Bug in J-Link GDB with data caching

    I am convinced this is a bug in J-Link GDB. Here's why:

    If I hit a breakpoint and try to use my debugger (via J-Link GDB) to view a variable, I get stale data. If I set the pc to the same position, it requests the exact same memory (as evidenced in the log) and gets a different answer.

    I then did a test with J-Link itself which bypasses the GDB stuff and goes straight to the pod. After hitting the breakpoint using the same tools, I then launch J-Link commander and view the memory. It's correct.

    In yet another test, I used the memory window to view the same memory using J-Link GDB (not j-link commander ). This time the memory was correct.

    I then decided to hit the breakpoint, not request any memory (set the pc to cursor again) then try to watch the pointer. It was stale. This tells me that in order to get the right data through GDB, you have to ask for it and THEN run to the same PC. Then it's correct. So somehow the act of asking for memory, running/stepping, then asking for it again gives you the right answer.

    The only thing I recently did to make this bug occur consistently (used to be only on occasion) was my addition of external cached EBI memory at address 0xD0000000. It seems as if stopping with the stack pointer in this range is triggering the issue. The thing is that even though I'm using this memory, the offending reads aren't even out of that memory. Not sure how this could be happening.

    Here's me hitting the breakpoint. The wrong value appears in the watch window. I then move the PC to the same line it's on and voila! The right value comes back. There are NO ISRS running (it's not that) and this happens to just about any variable you look at.

    Source Code

    1. ....unrelated memory reads...
    2. Read 4 bytes @ address 0x80000338 (Data = 0x000E6701) >>> THIS IS WRONG
    3. Read 4 bytes @ address 0x9D085A8C (Data = 0x240600DC)
    4. Read 4 bytes @ address 0x9D085A90 (Data = 0x8F828318)
    5. Setting breakpoint @ address 0x9D085A90, Size = 4, BPHandle = 0x0007
    6. Setting breakpoint @ address 0x9D085D80, Size = 4, BPHandle = 0x0008
    7. Setting breakpoint @ address 0x9D10BBF0, Size = 4, BPHandle = 0x0009
    8. Starting target CPU...
    9. ...Breakpoint reached @ address 0x9D085A90
    10. Reading all registers
    11. Removing breakpoint @ address 0x9D085A90, Size = 4
    12. Removing breakpoint @ address 0x9D085D80, Size = 4
    13. Removing breakpoint @ address 0x9D10BBF0, Size = 4
    14. ... removed unrelated memory reads...
    15. Read 4 bytes @ address 0x80000338 (Data = 0xD0022538) >>>> THIS IS CORRECT
    Display All

    The post was edited 7 times, last by Tj256 ().

  • Workaround... but painful. Please- I'm stuck! Hellllp!

    Hey Segger,

    I'm working around my latest issue here by making sure my watch window is empty when running, then once I break and I need to look at anything I enter it into the watch window then I refresh by doing the "setting the PC to the same line" trick. If I then want to open a struct, I open it but I have to do the same update trick again or I vector into a TLB exception.

    Microchip's tools are broke. I migrated to yours since they allowed me to view custom mapped memory regions. Unfortunately now that I am using EXTERNAL memory (Which is broke in microchip's tools) the fact my stack pointer is in a custom space (0xD0000000) seems to be confusing your tools. This shouldn't matter because for a year I was using TLB mapped RAM which should be the same deal. The only difference here ( I think) is that my new address space can't be "write through" by design. My hardware won't allow it. The transactions must be 16 bytes out the EBI. Maybe there's a funny cache bug going on here? This should be fine/legit. And all this is just a guess on what might be causing this issue. The bogus data is being returned from RAM (0x80000000) so I really am at a loss as to why this even matters.

    I'm not sure if this is going to get fixed. Given that the bug I reported a year ago where any viewing of a bad pointer causes an exception hasn't yet been fixed. These are what I'd call SHOWSTOPPERS. But there is nowhere else to turn. My project is dead in the water and I am now seriously considering writing my own GDB / JTAG debugger to recover from this. I hate the thought of having to write my own tools because none of the ones on the market work... but I don't know what else to do. I'm begging you guys-- I'm at your mercy. Can we try to fix this?


    Thanks,

    -Tj

    The post was edited 3 times, last by Tj256 ().

  • Hi,


    currently there is still very few demand for PIC32.
    Therefore, we cannot put a lot of time / manpower into investigation of this issue.
    We will put this on our internal ToDo, but we cannot provide a time schedule.
    We will get back on you when there is news regarding this issue.

    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Thanks-- but less demand now :)

    This is one of many issues I've run into with the J-Link/Pic32 and I've had to write my own GDB stub to fix this and others. So I'm no longer waiting on this issue. Thanks for getting back.