[SOLVED] oZone + IAR: ElfDwarf problems and unexpected break

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

  • [SOLVED] oZone + IAR: ElfDwarf problems and unexpected break

    Hey guys,

    I'm using oZone 2.56l on a Nordic nRF52832 connected by a J-Link Plus. Toolchain: IAR 8.11.2. I have two problems with this configuration lately:

    1. On loading the generated .out file, I get messages from oZone:

    Source Code

    1. File.Open ("C:/projects/foo/_build/foo.out");
    2. ElfLib: libdwarf: Debug info NULL in func _dwarf_strtab_init (.debug_str, 0x0)
    3. ElfLib: libdwarf: No Error in func _dwarf_loclist_add_locdesc (base address entry in location list unsupported, 0x0)


    It still loads the objectfile correctly though, debug information as far as I can tell seems to be correct and it stops at main as I expect it to.


    2. When running, the target stops somewhere in Nordic's softdevice, always on the same address and it won't continue from there. It didn't to do that a couple of oZone versions ago and it doesn't do that when using IAR's debugger either. There seems to be no reason to stop here whatsoever: no breakpoint set, no weird exception or anything. The instruction it stops on is a pretty simple LDR R3, [R3+0x0C] where R3 points on an address ending in 0x00 (so no alignment problems either). No memory protection.

    I'm lost. The reason I use oZone instead of IAR's debugger is its convenient RTT implementation and it provides better trace support when using our J-Trace Pro probe. I feel somewhat disabled using IAR's debugger, so if this can be fixed I would be very grateful.

    Edit: could it be this is the same problem as described here => [SOLVED] Ozone: v2.56 regression with Nordic SoftDevice (S140, nRF52840) ?
    Looks like it... the vector table lives not where oZone expects it to be!

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

  • Hello,

    Thank you for your inquiry.
    Regarding 1:
    Such an issue is not known to us. Could you provide the .elf file for reproduction?

    Regarding 2:
    This is most likely related to Ozone starting the application from where it has been downloaded to and not from 0x0 where the softdevice is located at.
    How to use a softdevice or bootloader with Ozone correctly is described in the latest Ozone user manual in section "6.3 Incorporating a Bootloader into Ozone’s Startup
    Sequence".

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

    Regarding 1:
    Such an issue is not known to us. Could you provide the .elf file for reproduction?

    Sure, see attachment. I took the BLE blink app from Nordic's SDK15, compiled for Nordic nRF52832 with an S132 softdevice. In order to reproduce my environment, you'ld need to flash the softdevice first (download the SDK from Nordic's website here, the softdevice is stored in ~/nRF5_SDK_15.0.0_a53641a/components/softdevice/s132, than load this compiled application through oZone (all using default settings).
    The executable is build using IAR EW for ARM, v8.11.2, debugger SEGGER oZone 2.56l.


    Regarding 2:
    This is most likely related to Ozone starting the application from where it has been downloaded to and not from 0x0 where the softdevice is located at.
    How to use a softdevice or bootloader with Ozone correctly is described in the latest Ozone user manual in section "6.3 Incorporating a Bootloader into Ozone’s Startup
    Sequence".

    The described process doesn't fly. It's meant for a bootloader that subsequently loads its application. We don't have that. I tried forcing PC and SP to the vector table from the SD (living at address 0x00000000 as per this thread but there still is a difference with a true reset somehow.
    Files
  • Hello,

    Thank you for providing the example project.
    We were able to launch the application without any issues on the PCA10040 eval board by setting the SP to the value at address 0x0 and the PC to the value at address 0x4.

    Attached is the jdebug file we were using. With it the application does not get stuck in the softdevice.
    Does it work with your setup using the attached Ozone project?

    Best regards,
    Nino
    Files
    • Ozone.jdebug

      (15 kB, downloaded 349 times, last: )
    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.