Cortex-A7 FPU registers D16-D31 wrongly displayed

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

    • Cortex-A7 FPU registers D16-D31 wrongly displayed

      Hello!
      Using latest Ozone (v3.38a) debugging .elf application for IMX6ULL (Cortex-A7), the second part of double precision registers (D16 to D31) are displayed incorrectly:


      It seems only lower 32 bits of the double register is intact, but high 32 bits are zeroed out for some reason.
      This is user interface only issue, registers contents are actually right and CPU execution goes as intended.

      In the J-Link web control panel these registers are fine with full 64 bit data:


      In IAR EW debugger all is fine also - double precision registers D0-D31 are displayed and edited OK.

      Regards, Vlad.

    • Hi Vlad,
      thanks for letting us know. We are not aware of such an issue.
      Which SVD file are you using? Is it `Cortex-A7.svd` that is coming with Ozone? Are you able to reproduce the issue on an eval board? If so: which one? Could you please provide a J-Link log recorded during a debug session where the issue is reproduced? The register window should show, a in your screenshot, both some registers where the display is correct (i.e. D0..D15) as well as registers where the display is incorrect (i.e. D16..D31). Could you also please provide a screenshot where the register content is displayed as hex value?
      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.

    • Hello, Alex.
      Yes, indeed i'am using .svd file from Ozone installation: C:/Program Files/SEGGER/Ozone V3.38a/Config/CPU/Cortex-A7.svd

      Board i'am working with is MYS-6ULX Single Board Computer from MYIR, i don't have any evaluation board, sorry.

      .log file is attached.
      Which is strange - in the log the D registers are seems to read fine in full 64 bits (and D29 is named as D39 for some reason):

      Source Code

      1. D16=0x0008000000200000
      2. D17=0x00
      3. D18=0x0008000000200000
      4. D19=0x0002000000040000
      5. D20=0x80001C0E80001C0E
      6. D21=0x80001C0E80001C0E
      7. D22=0x8FD01C0E8FC01C0E
      8. D23=0x8FF01C0E8FE01C0E
      9. D24=0x0CD004160CC00416
      10. D25=0x0CF004160CE00416
      11. D26=0x0D1004160D000416
      12. D27=0x0D3004160D200416
      13. D28=0x0D5004160D400416
      14. D39=0x0D7004160D600416
      15. D30=0x0D9004160D800416
      16. D31=0x0DB004160DA00416
      Display All
      And the screenshots:





      PS: attached board initialization script, in case it might be helpful.

      Regards,
      Vlad.
      Files

      • jlink.zip

        (40.65 kB, downloaded 53 times, last: )

      • ddr_init.zip

        (1.13 kB, downloaded 45 times, last: )

      The post was edited 1 time, last by sonycman ().

    • New

      Hi,
      thank you for providing the details. It appears to be the case that Ozone somehow swallows the upper 32 bits of the registers D16..D31.
      We will need to have a closer look for reproducing the issue locally.
      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.

    • New

      Hi Vlad,
      we are able to reproduce the issue. A fix will be provided in a future Ozone release.
      Thanks for notifying us!
      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.