[SOLVED] Ozone opens disassembly window on every target reset

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

  • [SOLVED] Ozone opens disassembly window on every target reset

    Hi,

    Before I submit the official bug report, I would like to ask here.

    Every time I reset the target (with F4 key or Debug->Reset menu) the Disassembly window opens up. But I don't need it! I've got all my necessary windows, Source, Data, Call Stack, etc, all open and properly placed. And yet Disassembly appears, which I need to close. Or, if it was already opened, it pops to the front. This is extremely annoying.

    I tried to add Window.Close("Disassembly"); to different hooks in my Ozone.jdebug file, to no avail. The debugger either complains "Unknown window" or does not attach to the target at all.

    What am I missing? Could you please point me to the relevant section in the documentation?

    I am using Ozone 3.10d in Linux, but this behaviour was there for years.

    Kind regards,

    Vadim

  • Hello Vadim,

    Thank you for your inquiry.
    The reported behavour usually happens when Ozone can't find the source files at the paths that are referenced in the elf file.
    To fix this you can either rebuild your application with your toolchain, then set up a new Ozone project which should set all paths automatically. Or you edit the .jdebug file yourself and set the Project.AddPathSubstitute to the correct paths.

    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.

  • Hi Nino,

    Thank you for your reply. Unfortunately, it does not help.

    First, I have added Project.AddPathSubstitute to my existing project file. Disassembly window still pops up on reset. Then, I have created the new project using the wizard. Nope, the same.

    I am using arm-none-eabi-gcc. The elf file is not stripped, so all the path information is there -- Ozone properly opens the file with main() function.

    Anything else I could try?


    And while I am fiddling with the .jdebug file, I have spotted another bug:

    Expansion indicators in the source window are always shown after loading Ozone, even if they have been disabled previously. PREF_SHOW_EXP_IDNICATORS (note the spelling) might be the reason.

    Kind regards,
    Vadim

  • Hello Vadim,


    vadim.b wrote:

    I am using arm-none-eabi-gcc. The elf file is not stripped, so all the path information is there -- Ozone properly opens the file with main() function.
    I am not saying the information is not there. But are the sources there? If not you have to do the path substitute or rebuild the application relative to the Ozone project path.

    Should it still not work could you provide an example project for reproduction?
    What target device are you debugging?
    Is it on an eval board or custom hardware? If eval board which one?


    vadim.b wrote:

    Expansion indicators in the source window are always shown after loading Ozone, even if they have been disabled previously. PREF_SHOW_EXP_IDNICATORS (note the spelling) might be the reason.
    Good catch. This is reproducible and should be fixed with the next Ozone release.

    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.

  • Hi Nino,

    I am using nRF52-DK board PCA10040 and nRF SDK 16.0.0 .

    The SDK is installed into the directory ~/work/nRF5_SDK_16.0.0

    Any example in the SDK will work, let's use examples/ble_peripheral/ble_app_template . This directory contains main.c and here the ozone.debug* files are located:

    Source Code

    1. ble_app_template> ll
    2. total 60K
    3. -rw-rw-r-- 511 Oct 18 17:59 ble_app_template.eww
    4. drwxrwxr-x 4.0K Oct 18 19:50 hex/
    5. -rw-rw-r-- 25K Oct 18 22:22 main.c
    6. -rw-rw-r-- 1.6K Mar 25 23:10 ozone.jdebug
    7. -rw-rw-r-- 2.3K Mar 25 23:10 ozone.jdebug.user
    8. drwxrwxr-x 4.0K Oct 18 17:59 pca10040/
    9. drwxrwxr-x 4.0K Oct 18 17:59 pca10040e/
    10. drwxrwxr-x 4.0K Oct 18 17:59 pca10056/
    11. drwxrwxr-x 4.0K Oct 18 17:59 pca10056e/
    Display All

    Ozone project file has the only function:

    C Source Code: ozone.jdebug

    1. void OnProjectLoad (void) {
    2. Project.AddPathSubstitute (".", "$(ProjectDir)");
    3. Project.SetDevice ("nRF52832_xxAA");
    4. Project.SetHostIF ("USB", "682702631");
    5. Project.SetTargetIF ("SWD");
    6. Project.SetTIFSpeed ("1 MHz");
    7. Project.AddSvdFile ("$(InstallDir)/Config/CPU/Cortex-M4F.svd");
    8. Project.AddSvdFile ("$(ProjectDir)/../../../modules/nrfx/mdk/nrf52.svd");
    10. File.Open ("$(ProjectDir)/pca10040/s132/armgcc/_build/nrf52832_xxaa.out");
    11. }
    Display All


    To build the project and start Ozone:

    Source Code

    1. ble_app_template> cd pca10040/s132/armgcc
    2. armgcc> make
    3. armgcc> cd -
    4. ble_app_template> Ozone


    Now, when I connect to the target (F5) and on every reset (F4) the Disassembly window opens up.


    The source files, object files, and the elf file are located in four places:
    • main.c is in ./ (dot)
    • SDK sources are in ../../../
    • objects are in pca10040/s132/armgcc/_build/nrf52832_xxaa/
    • elf file is in pca10040/s132/armgcc/_build/
    The map file shows all object paths relative to _build/nrf52832_xxaa/


    I am a bit lost which path substitute should I use (apparently, it should be only one?)


    Kind regards,

    Vadim

  • Hello Nino,

    I think I know what is going on.

    SEGGER - Nino wrote:

    The reported behavour usually happens when Ozone can't find the source files at the paths that are referenced in the elf file.
    Attached is the screenshot of two windows: Disassembly and Call Stack. The breakpoint is at main() because of VAR_BREAK_AT_THIS_SYMBOL. It was called from _mainCRTStartup which is located in GCC's ~/bin/gcc-arm-none-eabi-9-2019-q4-major/arm-none-eabi/lib/thumb/v7e-m+fp/hard/crt0.o file. Which, in turn, does not have associated source file.



    If my assumption is correct, I still don't see the reason for the Disassembly window to appear each time the PC passes from reset vector to main -- there are no breakpoints placed before main(). And if I'd like to see the disassembly, I would just double click on _mainCRTStartup in Call Stack window.

    Kind regards,

    Vadim