[SOLVED] Software breakpoint does not work with Segger tools 5.12f

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

  • [SOLVED] Software breakpoint does not work with Segger tools 5.12f

    I made several tests, and the software breakpoint works with the Segger tools version 5.10m, but it doesn't with the latest version.
    I use the same software, hardware, and debug probe. This is my setup:
    • JLinkARM.dll version `V5.12f`
    • Target device `nRF51822_xxAA`
    • Firmware: J-Link Lite-Cortex-M V8
    • GNU ARM C/C++ J-Link Debugging version `3.2.1.201604190915`
    • arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) version `5.3.1 20160307`

    In exactly the same environment, with the same project, with multiple SEGGER J-Link software installed in separate folders, if you change the path (in Preferences -> Run/Debug -> SEGGER J-Link) and with 5.10m it works and with 5.12f it does not.

    This is the code I use:


    static inline void break_here(void) {
    /* __asm volatile(
    "bkpt #0x01\n\t"
    "mov pc, lr\n\t"
    ); */

    __BKPT(0);
    }

    Please find attached the full log files for both version. Can you help me to analyze these files and figure-out why it is not more working with the latest version of the Segger tools ?

    Thanks in advance.
    Files
  • Hi,

    i just gave it a try and it worked just fine with the current beta version (V5.41d)
    Could you give the current beta version a try?
    if it does not work, could you please give J-Link Commander a try?
    J-Link commander is part of the J-Link software package, which is available free of charge here .

    • Start J-Link Commander (jlink.exe)
    • Type "connect" in order to start a debug session
    • Type in the target device name if asked (Or type "?" for a target selection Dialog)
    • Choose the correct target interface (JTAG/SWD/etc..)
    • Use a valid speed (Default: 4000kHz, try 100-500 if default does not work)
    • [JTAG only]JTAG conf can be default(most of the times)
    • You should now be successfully connected.
    If anything fails, could you post a screenshot of the complete session and a J-Link log file?

    Log output can be enabled like as follows:
    • Open a connection to J-Link, e.g start J-Link Commander
    • In J-Link Control Panel: (Click the J-Link symbol located in the notification / tray area in order to open J-Link Control panel)
    • Open the tab "Settings"
    • Next to the field "Log file" check "Override" and click "..." in order to choose a log file path.

    This is also described in UM8001 Chapter 5 "Working with J-Link and J-Trace", Section 5.7 "J-Link control panel" .

    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.
  • gdb 7.10 & bkpt

    the problem with bkpt is a mismatch between the current J-Link GDB server and GDB client v7.10.

    it was reported and probably be fixed soon.

    until then, as a workaround, use GDB 7.8.
  • Hi Forum,

    this issue has been fixed with version 5.41i of the J-Link software package .

    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.
  • SEGGER - Niklas wrote:

    Hi Forum,

    this issue has been fixed with version 5.41i of the J-Link software package .

    Best regards,
    Niklas
    Hi Niklas and ilg,

    Thank you for your support.
    @Niklas according to the changelog, it seems to be available in V5.12h. Is this correct ?
    We are pleased to announce the availability of a new version of the J-Link software and
    documentation pack V5.12h with the following changes:


    - DLL: Silicon Labs EFM8 series devices: Under special circumstances, it could happen that high-level (C-source) stepping in the IDE did not work correctly. Fixed.
    - DLL: Silicon Labs EFM8 series devices: Under special circumstances, it could happen, that breakpoints were not hit if a memory read/write request was issued by the IDE, while the CPU was running. Fixed.
    - DLL: Under special circumstances, disassembly of Cortex-AR big endian devices did not work properly. Fixed.
    - GDB Server: GDB 7.10 did not break on bkpt instruction due to wrong stop reason. Fixed.
    - J-Link Commander: J-Link command files were opened using single access instead of shared access. Fixed.

    The software can be downloaded from the following location:
    http://www.segger.com/jlink-software.html
    @ilg I will test this change tomorrow with the latest version of the GNU ARM Eclipse.
  • Hi,

    I am still seeing this issue (at least partially) with the very latest beta JLinkGDBServer (64-bit linux), LPC54102J512 MCU and GDB from latest GCC ARM embedded (7.10.1.20160210-cvs)... GDB 7.6 from earlier version works ok.


    JLinkARM.dll V5.41j (DLL compiled Jun 29 2016 18:23:14)

    Using target extended-remote, if I set a breakpoint on Reset_Handler and instruct GDB to "run" (after load), I can see JLinkGDBServer itself breaking ok:


    Setting breakpoint @ address 0x0000013A, Size = 2, BPHandle = 0x0001
    Starting target CPU...
    ...Breakpoint reached @ address 0x0000013A
    Reading all registers
    Read 4 bytes @ address 0x0000013A (Data = 0xF2C423C8)

    But GDB itself does not react to this at all.. it's just stuck.


    However, if I do the same thing but tell GDB to "continue" instead of "run", then breakpoint works ok:


    (gdb) c
    Continuing.

    Breakpoint 1, Reset_Handler () ...

    So it seems that at this point this might be only partially fixed? Any insight from Segger? Thanks!
  • Hi Forum,


    @metch

    Good to hear that you are up and running.

    @uusirant

    The inital bug should be fixed completely, not just partly :)
    Could you provide us with an reproduction project, so that we can take a look at it?


    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.
  • This is as closely as I can instruct.. I could send a test binary for LPC54 if you send me your email address in a PM.

    1. I have a simple elf file, Reset_Handler is the reset vector.

    2. Start JLinkGDBServer in terminal:

    JLinkGDBServer -device lpc54102j512 -if swd -speed 1000 -vd

    3. arm-none-eabi-gdb --version
    GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160210-cvs

    4. Start GDB session:

    gdb --se=test.elf

    5. Reading symbols from test.elf...done.
    (gdb)


    6. GDB commands used to init and load

    target extended-remote localhost:2331
    monitor speed 1000
    monitor endian little
    monitor flash cpuclock = 96000000
    monitor flash device = LPC54102J512
    monitor flash download = 1
    monitor flash breakpoints = 1
    monitor exec SetSkipProgOnCRCMatch=0
    monitor exec SetVerifyDownload=6
    monitor reset
    load

    7. Set breakpoint on Reset_Handler:

    (gdb) b Reset_Handler
    Breakpoint 1 at 0x13a: file cr_startup_lpc5410x.c, line 356.

    8. Try to run (instead of continue.. it's pretty convenient to use run for restarting in one session):

    run

    9. JLinkGDBServer resets CPU and does breakpoint OK:

    Reset target CPU...
    Reset target CPU...
    Reading all registers
    Read 2 bytes @ address 0x0000013A (Data = 0x23C8)
    Setting breakpoint @ address 0x0000013A, Size = 2, BPHandle = 0x0002
    Starting target CPU...
    ...Breakpoint reached @ address 0x0000013A
    Reading all registers
    Read 4 bytes @ address 0x0000013A (Data = 0xF2C423C8)


    -> BUT, GDB does not react at all, it's basically stuck at this point.. breaking with CTRL+C times out:

    Starting program: test.elf
    ^C^CInterrupted while waiting for the program.
    Give up waiting? (y or n)


    As far as I can see, GDB 7.6 works, 7.8 seems to already have this issue..
  • Hi,


    PM sent.

    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.
  • Hi Jani,

    thanks for providing the .elf file.
    I forwarded it to our GDB Server maintainer.

    He said that this seems to be different issue, as you are referring to setting BPs via GDB Server, but the initial issue discussed in this thread has been software BP which were already in flash memory.

    Nevertheless, he will of course check if we are doing sth. wrong.

    Please note that we currently have an annual event here at SEGGER, therefore investigation will most likely not begin before the end of next week.

    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.