[SOLVED] WARNING: No more breakpoint resources left

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

  • [SOLVED] WARNING: No more breakpoint resources left

    Hello,
    I'm currently in the process of debugging a arm cortex m0 target using gdb and the Jlink debug server. My .gdbinit looks like this:

    C Source Code

    1. target remote localhost:2331
    2. monitor speed 1000
    3. monitor flash breakpoints = 1
    4. monitor flash download = 1
    5. monitor flash device = nRF51422_xxAA
    6. # monitor endian big
    7. monitor reset
    8. break _start


    When I going through the program execution in some situations, I can not single step. One of such situations is a call to memset(). When I try to single step over the call, the debugger does not stop execution behind the function call. The output of the debug server in this case is: WARNING: No more breakpoint resources left

    This is the output of the debug server after starting and attaching a gdb:

    C Source Code

    1. SEGGER J-Link GDB Server V4.88a Command Line Version
    3. JLinkARM.dll V4.88a (DLL compiled Jul 17 2014 18:24:01)
    5. -----GDB Server start settings-----
    6. GDBInit file: none
    7. GDB Server Listening port: 2331
    8. SWO raw output listening port: 2332
    9. Terminal I/O port: 2333
    10. Accept remote connection: yes
    11. Generate logfile: off
    12. Verify download: off
    13. Init regs on start: on
    14. Silent mode: off
    15. Single run mode: off
    16. Target connection timeout: 5 sec.
    17. ------J-Link related settings------
    18. J-Link Host interface: USB
    19. J-Link script: none
    20. J-Link settings file: none
    21. ------Target related settings------
    22. Target device: nRF51422_xxAA
    23. Target interface: SWD
    24. Target interface speed: 1000kHz
    25. Target endian: little
    27. Connecting to J-Link...
    28. J-Link is connected.
    29. Firmware: J-Link OB-SAM3U128 V1 compiled Dec 11 2013 20:20:11
    30. Hardware: V1.00
    31. S/N: 480208075
    32. Checking target voltage...
    33. Target voltage: 3.30 V
    34. Listening on TCP/IP port 2331
    35. Connecting to target...Connected to target
    36. Waiting for GDB connection...Connected to 127.0.0.1
    37. Reading all registers
    38. Read 4 bytes @ address 0x00000000 (Data = 0x00000000)
    39. Target interface speed set to 1000 kHz
    40. Flash breakpoints enabled
    41. Flash download enabled
    42. Selecting device: nRF51422_xxAA
    43. Resetting target
    44. Read 2 bytes @ address 0x000200D6 (Data = 0xF000)
    45. Read 2 bytes @ address 0x000200D6 (Data = 0xF000)
    46. Read 2 bytes @ address 0x000200D6 (Data = 0xF000)
    47. Read 2 bytes @ address 0x00020A76 (Data = 0xE7FE)
    48. Read 2 bytes @ address 0x00020A76 (Data = 0xE7FE)
    Display All


    and here its some of the output during a debug session, until the problem occurs:

    Source Code

    1. Removing breakpoint @ address 0x0002075E, Size = 2
    2. Removing breakpoint @ address 0x0002079C, Size = 2
    3. WARNING: Breakpoint @ address 0x0002079C not found
    4. Removing breakpoint @ address 0x000207B6, Size = 2
    5. WARNING: Breakpoint @ address 0x000207B6 not found
    6. Removing breakpoint @ address 0x00020A76, Size = 2
    7. WARNING: Breakpoint @ address 0x00020A76 not found
    8. Setting breakpoint @ address 0x000200D6, Size = 2, BPHandle = 0x0341
    9. Setting breakpoint @ address 0x00020144, Size = 2, BPHandle = 0x0342
    10. Setting breakpoint @ address 0x0002032E, Size = 2, BPHandle = 0x0343
    11. Setting breakpoint @ address 0x0002075E, Size = 2, BPHandle = 0x0344
    12. Setting breakpoint @ address 0x0002079C, Size = 2, BPHandle = 0x0000
    13. WARNING: No more breakpoint resources left
    14. Setting breakpoint @ address 0x000207B6, Size = 2, BPHandle = 0x0000
    Display All


    When I use "stepi" to get behind the memset() function call, I can use single steps again. So it's not wrong arguments to memset() that is causing my problems here.
    Can someone of you spot what I'm missing here?

    Kind regards and thanks in advance,
    Torsten

  • At least it seems not to be a resource limit. If I set a break point behind a memset() function where I want to step over, the debugger stops at that breakpoint. So now I'm debugging by watching the source code, setting a breakpoint behind every function call and using 'c' to step to this break point.

  • This usually means that your device has run out of hardware breakpoints. One is used for single stepping so if you have a couple more set then you may be out. You may only have two total but I'd have to look that up. It wouldn't surprise me on this core.

    Does your JLink have the flash breakpoints feature? This is how I solved this on a Cortex-M3 (Analog Devices ADUCM320) that only had two hardware breakpoints.

    Sometimes I build the code to run completely or mostly out of RAM so that I can use as many software breakpoints as I need. Of course you are probably limited on RAM as well but it may be worth a try. Just remember to set the VTOR in the system control block is you move your interrupt vectors to RAM as well. If you are just debugging one file then you could just place that in RAM.

    K

  • Hi Kenny,
    thank you for taking a look at my issue. I think I've enabled flash breakpoints and as the debug server response with `Flash breakpoints enabled`, I think that Flash breakpoints are supported. I'm quit sure that I've used more than two breakpoints already.

    I've send also an email to the segger support, but didn't got response so far. In addition, I've installed the latest JLink software, but that didn't solved the problem.

    cheers,

    Torsten

  • I see that you are using a JLink "On Board".

    Apparently these have the same features as JLink Base in which case the Flash Breakpoints feature may be in evaluation mode. On Windows it will annoyingly prompt you to enable it each time once you run out of breakpoints. The driver will do this so if you start with no breakpoints and start adding them it would pop up at some point. On Linux or OSX perhaps they don't have support for the pop-up in the driver so it may be silently failing? This is based on some experience I had using GDB on OSX so not pure speculation but not necessarily correct either :)

    What platform are you using? On Windows there is a control panel that will show breakpoint capabilities (see attached). You can also try some controlled experiments from JLink commander (just JLink.exe on Linux/OSX I think) by using the SetBP and ClrBP commands. You could use SetBP and then read back the memory to verify that it is indeed the correct instruction.

    Perhaps that feature is indeed enabled but the flash driver has a bug? The experiments above may help point this out.
    Images

    • Screen Shot 2014-08-27 at 9.52.23 AM.png

      82.94 kB, 846×573, viewed 1,094 times

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

  • I suppose it is as Kenny described it. If there's an annoying message or what ever on windows every time the debugger runs out of hardware breakpoint they simply disabled that on linux....
    I'm on linux and run into this issue and have no idea how to enable the unlimited flash breakpoint feature.

    maybe someone from segger may comment on this if the evaluation on the unlimited flash breakpoint feature is possible on linux or not and if it is how to do so.

  • Hi,

    Currently, it is indeed not possible to evaluate flash breakpoints under Linux / OS X.
    If you are a non-commercial user, the J-link EDU might be the right choice for you and it also allows using flash breakpoints (it comes with a built-in license). We are currently thinking about ways to allow evaluation of flash breakpoints under Linux / OS X, but this possibly requires some major changes, so there is no specific timeframe yet.


    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.

  • Hi Alex,
    thanks for replying to this topic. When I try to apply your answer to my original post / problem, does it mean that it is not possible to debug under OS/X with more than 2 break points?

    What would be a viable approach to single step through code? Should it work, if I use just one break point, so that the debugger can use the second hardware break point to implement single step debugging?

    TIA Torsten

  • Hi Thorsten,

    First of all, most devices have more than 2 hardware breakpoints.
    Second, even on the ones that only have 2 hardware breakpoints, you can debug. There simply is that limit of
    2 breakpoints:
    Unless you can use "Unlimited Flash breakpoints", which means J-Link reprograms the flash if it has to.
    You will need a J-Link PLU, Ultra+ or PRO to do this. Under WIndows, a message box for
    easy evaluation will pop up. Under MAC OS, it seems that is not implemented. I guess SEGGER should be able
    to send a license file for MAC OS, or add least be able to add a functionality like that.
    Also: Single STeps (Instruction steps) should work in any case.
    @Alex: Would not it be possible to read a license file on MAc OS so prospects can get a temporary license?

  • Hi Mike,
    Ok, so it's just an license issue with the Nordic evaluation board? If I'm using our own target hardware and a JLink PRO, I should be able to debug and should not see the problems above? That would be good news as that will be the setup I have to work with next week :)

    Cheers,

    Torsten

  • Hi,

    Just in addition to Mike's post:

    • Single instruction stepping on Cortex-M does not even need a breakpoint. It will also work if all available hardware breakpoints are already used
    • Using a higher end model (PLUS, ULTRA+, PRO) you can use "Unlimited Flash Breakpoints" under Windows (without the dialog popping up), as well as under Linux & Mac.
    • It will be possible to evaluate "Unlimited Flash Breakpoints" under Linux / Mac too, in the future. Maybe in a way Mike proposed (having a license file placed in the folder where the J-Link shared library is located).


    Thorsten:
    Ok, so it's just an license issue with the Nordic evaluation board?

    The J-Link OB on the Nordic board does not come with a license for "Unlimited Flash Breakpoints", so under Linux/Mac(!) only the 2 hardware breakpoints of the nRF51 can be used, while debugging in flash.

    If I'm using our own target hardware and a JLink PRO, I should be able to debug and should not see the problems above?

    Correct.


    - 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.

  • Hi Alex

    Thanks for your answer (although a little bit disappointing for all *nix users, but at least I know now it's not a configuration issue)

    I hope Segger will solve this issue very soon with an updated version of the gdb server. using an stand alone JLink is not always the best solution (although possible) especially if you start your development on an eval board like one of Freescale's FRDM-*

    /martin

    The post was edited 2 times, last by mgysel ().