[SOLVED (HW bug)] Clarity on GDB Server and GDB Error Messages

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

  • [SOLVED (HW bug)] Clarity on GDB Server and GDB Error Messages

    OSX 10.11.4, GDB Server v5.12e
    I'm chasing an elusive bug on an STM32F415. It looks as if it is resetting as it prints a message that only happens during boot.

    I'm using OSX and tried to use Ozone. I set a breakpoint in main() but when I induced the error the processor did not halt. I set a breakpoint in the one and only place where the message is printed and it also did not halt on failure. Unfortunately I got to a place where Ozone kept crashing that I do not think is related to my bug. (I do like the tool).

    I switched to GDB and when the error occurs the server complains that it cannot read certain registers when the CPU is running. The GDB client receives SIGTRAP.

    After this I try to read the RCC_CSR to determine the reset cause but it cannot be read. I'm wondering if I'm getting a brown-out and the JLink communications are lost? If this is the case I'd probably lose my hardware breakpoints as well and all bets are off.

    Why wouldn't the JLink detect this condition on the Vtarget pin? Or that just a slow periodic polling thing?

    Thanks,

    Kenny

    GDB Server

    Source Code

    1. Starting target CPU...
    3. ERROR: Can not read register 15 (R15) while CPU is running
    4. Reading all registers
    5. ERROR: Can not read register 0 (R0) while CPU is running
    6. ERROR: Can not read register 1 (R1) while CPU is running
    7. ERROR: Can not read register 2 (R2) while CPU is running
    8. ...ERROR: Can not read register 55 (FPS22) while CPU is running
    10. ERROR: Can not read register 56 (FPS23) while CPU is running
    11. ERROR: Can not read register 57 (FPS24) while CPU is running
    12. ERROR: Can not read register 58 (FPS25) while CPU is running
    13. ERROR: Can not read register 59 (FPS26) while CPU is running
    14. ERROR: Can not read register 60 (FPS27) while CPU is running
    15. ERROR: Can not read register 61 (FPS28) while CPU is running
    16. ERROR: Can not read register 62 (FPS29) while CPU is running
    17. ERROR: Can not read register 63 (FPS30) while CPU is running
    18. ERROR: Can not read register 64 (FPS31) while CPU is running
    19. Read 4 bytes @ address 0x00000000 (Data = 0x20020000)
    20. Reading from address 0x40023874 (Failed)
    21. Writing 0x01000000 @ address 0x40023874
    Display All


    GDB Session

    Source Code

    1. (gdb) monitor reset
    2. Resetting target
    3. (gdb) source rcc.py
    4. Reading from address 0x40023874 (Data = 0x14000000)
    5. Writing 0x01000000 @ address 0x40023874
    6. (gdb) source rcc.py
    7. Reading from address 0x40023874 (Data = 0x00000000)
    8. Writing 0x01000000 @ address 0x40023874
    9. (gdb) c
    10. Continuing.
    12. Program received signal SIGTRAP, Trace/breakpoint trap.
    13. 0x00000000 in ?? ()
    14. (gdb) source rcc.py
    15. Reading from address 0x40023874 (Failed)
    16. Writing 0x01000000 @ address 0x40023874
    Display All

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

  • Hello Kenny,

    When the target device resets the whole debug connection might be lost,
    because a reset might also reset the debug unit and it will usually clear all HW-breakpoints.

    You could try setting a vector catch on the reset vector instead of a breakpoint.

    There isn't much the J-Link can do to get the reset or to automatically reconnect after reset.

    Best regards
    Johannes
    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.

  • Hi Kenny,

    Why wouldn't the JLink detect this condition on the Vtarget pin? Or that just a slow periodic polling thing?

    Yes, it is a slow periodic polling thing. Even if it would not, there is always a timeframe where a brown-out might not get detected and depending on where it happens, a re-init of the debug session etc. may be impossible without restarting the whole thing.
    If you want to debug reliably, the hardware (at least the parts that affect debug) need to work reliably.


    Best regards
    Alex
    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 for the support. It turned out that the STM32F4 PDR_ON pin was left floating in the design which lead to unpredictable behavior. Fortunately VDD is pin 144 and PDR_ON is pin 143 so I was able to simply bridge the two and everything is fine.

    Sorry for the false alarm.