[SOLVED] Ozone and IAR EW for ARM symbols not working with breakpoints properly on STM32L496QG

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

  • [SOLVED] Ozone and IAR EW for ARM symbols not working with breakpoints properly on STM32L496QG

    I have a project that needs to be built on IAR EW for ARM and try to debug it from Linux.

    I can see all symbols in the resulting ELF, however I can't break on "main symbols", IAR creates bunch of partial symbols, including "main symbols".

    E.g. there is method/function SPCmd::HandleCmdData, but the code never breaks on it. I have to add all extra breakpoints on symbols weirdly named HandleCmdData_xx (where xx is 0 to 23). This includes lots of flash breakpoints. And it applies to all of the other methods/functions.

    Versions:
    * Ozone v3.28b (latest version) on Linux (where it's debugged) with JTrace
    * IAR EW for ARM 9.30.1 on Windows (where executable is built)

    See screenshot where I have breakpoint on SPCmd::HandleCmdData, but it never gets hit, instead HandleCmdData_0 is hit. I tried turning off all optimizations in IAR EWARM, but nothing seem to work. The main functions/methods are never hit if set as breakpoints.
    Images

    • Ozone_energizer_IAR_weird_symbols_03_blurred.png

      540.9 kB, 1,960×1,091, viewed 288 times

  • Hi Zamniah,

    our first guess is that SPCmd::HandleCmdData() is inlined and ??HandleCmdData_## represent the locations where the inlining actually takes place. If so, the ELF file does not tell Ozone about that inlining, otherwise setting a BP on SPCmd::HandleCmdData() would have caused a BP being set onto each ??HandleCmdData_##.

    Our 2nd guess is that the code is optimized (but you stated that you disabled optimization).

    Another option might be that the tool chain created debug information in DWARF5-format. If so, please switch to DWARF4 since Ozone does not yet fully support DWARF5.

    And last but not least BPs being set on sources but not being hit is often seen in cases where the sources do not match the binary. Since you state that you do the build on a Windows machine but do the debugging on a Linux machine it might happen that the source code base on both machines differs.

    Best regards
    -- AlexD
    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 reply.

    I had set up a shared folder between host and VM, so that Ozone will always ask you if you want to reload the ELF once it changes.

    The fix or workaround was changing optimization settings in IAR EWARM (I checked the DWARF version and it says 4).

  • Hi Zamniah,

    so the issue is gone now and you resolved it by disabling optimization in IAR EWARM?

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

  • The answer will look weird, but I had either to completely disable optimizations, or to enable max "high" optimization in EWARM. But nothing in-between.

    (With disabled optimization the ST bluetooth chip wouldn't work for some commands, it would report command of zero length for "OpenSession" command, other went through OK).

    So in the end I went for the "high" optimization, which was a bit PITA (many variables optimized out), but I got IV, key, plaintext, ciphertext that was relevant for the case.

    (Though I am still baffled why it all happened - it wasn't like it was some softdevice)

    I even got BLE sniffers for this, but they didn't help to resolve it.

    Sorry if I can't be more clearer, but I just don't really know (FYI it was RTOS and the BLE had IIRC pretty high priority - Bluetooth had priority High (3) and HalBLueNRG Highest (4)

  • Hi Zamniah,

    good to hear that you are up and running now.

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