[SOLVED] Break.SetCmdOnAddr broken from 3.20d and onwards

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

  • [SOLVED] Break.SetCmdOnAddr broken from 3.20d and onwards

    Hi,

    First of - thank you for a great product!

    I'm having issues with one of my projects using the Break.SetCmdOnAddr function. In 3.20c it works fine, but in 3.20d and onwards the callback is not added to the breakpoint.
    Break.SetCommand works as expected.

    Using the following project file (Modified Ozone_Automation_Demo_ST_STM32F407.zip)

    C Source Code

    1. void OnProjectLoad (void) {
    2. Project.SetDevice ("STM32F407IE");
    3. Project.SetHostIF ("USB", "");
    4. Project.SetTargetIF ("SWD");
    5. Project.SetTIFSpeed ("4 MHz");
    6. Project.AddSvdFile ("Cortex-M4.svd");
    7. Project.AddSvdFile ("STM32F407IG.svd");
    8. Project.AddPathSubstitute("C:/Work/TestProjects/J-Trace_PRO_CortexM_Tutorial/Start", "$(ProjectDir)");
    10. Project.AddPathSubstitute("c:/work/testprojects/j-trace_pro_cortexm_tutorial/start", "$(ProjectDir)");
    12. File.Open ("./Output/Debug NoOS NoSystemInit/SEGGER Cortex-M Trace Reference Board.elf");
    13. Debug.SetResetMode(RM_RESET_AND_RUN);
    15. Break.Set(0x8008260);
    16. Break.SetCmdOnAddr(0x8008260,"OnBPHit");
    17. }
    19. void OnBPHit(void) {
    20. Util.Log("---BP hit!---");
    21. }
    Display All


    3.20d console output:

    ...
    Break.Set (0x08008260);
    Break.SetCommand ("0x08008260", "OnBPHit");
    Break.SetCommand ("0x08008260", "OnBPHit"): Breakpoint not set: 0x08008260
    File.Open: completed in 111 ms



    3.20c console output:
    ...
    Break.Set (0x08008260);
    Break.SetCommand ("0x08008260", "OnBPHit");
    File.Open: completed in 172 ms

    Best regards,

    Rune

  • Hello Rune,

    Thank you for your inquiry.
    I just gave this a quick try with the latest Ozone version V3.22a and everything was working as expected.
    Do you see the issue with the latest Ozone version?

    Best regards,
    Nino
    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.

  • Hello Nino,

    Thank you for the feedback!

    Same behaviour in V3.22a - "breakpoint not set" is printed in the console on project load. I've attached an elf file and .jdebug file for your convenience (just the same project / elf as I referred to earlier).

    Also attached is a screendump from 3.22a - note the question mark in "Extras".

    I am able to manually add the callback by modifying the breakpoint (F8 -> Extra Actions -> Script Callback)




    Regards,
    Rune
    Images

    • ozone_322a_setCmdOnAddr_issue.png

      66.43 kB, 1,740×434, viewed 396 times
    Files

  • Hello Rune,

    I just gave the Wiki example another try and it works out of the box for me.
    Does the original Wiki example work for you as well?

    You seem to have modified it afterwards. Is there even application code at address 0x08008260 where a breakpoint could be set?
    Is there a particular reason you are use the address directly and not the file or symbol information from the current application?

    Best regards,
    Nino
    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.

  • Hello Nino,

    Indeed the wiki example works out of the box. The wiki example uses Break.SetOnSrc which works, but after modifying the project with Break.SetCmdOnAddr it no longer works.

    The specified address 0x08008260 is within valid flash memory space, but not within the application image memory range as you pointed out (the used location was copied from another project).

    Modifying the wiki example to use the memory location instead of the source location (main.cpp:128 -> 0x080005D2) gives the same result - "breakpoint not set".

    C Source Code

    1. //
    2. // Set BP on source line 128 in TraceDemo.c
    3. //
    4. // DISABLED Break.SetOnSrc("TraceDemo.c:128");
    5. //
    6. // Set Function which should be executed once BP is hit
    7. //
    8. // DISABLED Break.SetCommand("TraceDemo.c:128","OnBPHit");
    9. //
    10. // Set BP on same address as source line 128 in TraceDemo.c
    11. //
    12. Break.Set(0x80005d2);
    13. //
    14. //Set Function which should be executed once BP is hit
    15. //
    16. Break.SetCmdOnAddr(0x80005d2,"OnBPHit");
    Display All



    Regarding the use case for Break.SetCmdOnAddr we use it for debugging a multi-application scenario.

    We start by loading symbol information from two applications and a bootloader and extract their start address (Elf.GetEntryPointPC()) and set the breakpoints callback functions using Break.SetCmdOnAddr()

    When the application runs and one of the start addresses are hit we load the appropriate application debug information using File.Load()

    Using Break.SetCmdOnAddr() in combination with Elf.GetEntryPointPC() seemed more general than using Break.SetCommand() since line numbers can change and we would like to avoid changing the project file too often. Furthermore, I am not sure that Break.SetCommand() can be used when the symbols are no longer loaded? I.e. is a breakpoint from Application A still viable when Application B is loaded?

    Best regards,

    Rune

  • Hello,

    I just gave your sample snippet a try and it is working for me.
    Could you give the attached Ozone project a try?
    Simply use it from the same folder as the example project.

    Does this work for you?

    rals wrote:

    Using Break.SetCmdOnAddr() in combination with Elf.GetEntryPointPC() seemed more general than using Break.SetCommand() since line numbers can change and we would like to avoid changing the project file too often.
    I see, makes sense, thank you for clarifying.

    rals wrote:

    Furthermore, I am not sure that Break.SetCommand() can be used when the symbols are no longer loaded? I.e. is a breakpoint from Application A still viable when Application B is loaded?
    Once the breakpoints are set, it should not matter if you load new symbols. The BP is already saved and translated to an address for the current symbol context when Break.SetCommand() was used.

    Best regards,
    Nino
    Files
    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.

  • Hello Nino,

    Thank you for the supplied example project. Sadly, it doesn't work for me. The breakpoint is hit, but the callback is not executed.

    I expect "---BP hit!---" to be written to the console which doesn't happen in 3.22a.

    Have you tried clearing the breakpoints (or deleting .jdebug.user file) and reloading the project?


    If the breakpoint and scriptCallback is already present in the .jedebug.user, the scriptcallback is executed and "---BP hit!---" is output to the console.

    So, to get your example to work I could use the following workaround:

    1) delete .jedebug.user / or clear breakpoints
    1) open the project in 3.20C
    2) close 3.20C
    3) open 3.22a
    4) the scriptcallback is executed when I expect it to be.

    Hope this helps

    Have a nice weekend,

    Rune

  • Hi Rune,

    Oh ok, that way it is reproducible for me. Very strange.
    We will investigate further and come back to you once we know more.

    Best regards,
    Nino
    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.