oZone + IAR: ElfDwarf problems and unexpected break

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

    • 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 ().

    • New

      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: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      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 contact us per e-mail.
      The following contact form can be used for this: segger.com/about-us/contact-us/

    • New

      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