Is this a bug of OZone? [bit field handling ]

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

  • Is this a bug of OZone? [bit field handling ]

    Hi,

    I am debugging STM32F769NI using OZone[ V2.32]. The ELF file was generated by
    gcc.

    Currently data bit fields other than 32 bits can not be displayed correctly.

    For example, in the case of code like the following, it will look like the attached figure.
    Is there a way to display the bit field of 8-bit or 16-bit data correctly?
    I have confirmed that other debuggers can display correctly.


    Source Code

    1. typedef union {
    2. uint32_t u32_val ;
    3. struct {
    4. uint32_t u4_val0 : 4 ;
    5. uint32_t u4_val1 : 4 ;
    6. uint32_t u4_val2 : 4 ;
    7. uint32_t u4_val3 : 4 ;
    8. uint32_t u4_val4 : 4 ;
    9. uint32_t u4_val5 : 4 ;
    10. uint32_t u4_val6 : 4 ;
    11. uint32_t u4_val7 : 4 ;
    12. } item ;
    13. } uni_u32_test_t ;
    14. typedef union {
    15. uint16_t u16_val ;
    16. struct {
    17. uint16_t u4_val0 : 4 ;
    18. uint16_t u4_val1 : 4 ;
    19. uint16_t u4_val2 : 4 ;
    20. uint16_t u4_val3 : 4 ;
    21. } item ;
    22. } uni_u16_test_t ;
    23. typedef union {
    24. uint8_t u8_val ;
    25. struct {
    26. uint8_t u4_val0 : 4 ;
    27. uint8_t u4_val1 : 4 ;
    28. } item ;
    29. } uni_u8_test_t ;
    30. uni_u32_test_t gu32_test = { .u32_val = 0x12345678 };
    31. uni_u16_test_t gu16_test = { .u16_val = 0x1234 };
    32. uni_u8_test_t gu8_test = { .u8_val = 0x12 };
    Display All


    Regards
    　masa

  • I can confirm this as well, and in addition, I found a related bug.

    Ozone treats a int32_t array inside a struct as an array of 8-byte integers (long long), but it should be 4-byte integers. This makes the variable display of structs incorrect.

    It does not seem to happen to uint32_t arrays inside structs.
    I am compiling with arm-none-eabi-gcc. I saw this in Ozone 2.32 and it persists in 2.40b

    In the attached screenshot, you can clearly see the error:
    In the variable watch window, the elements defined as int32_t are given 8 bytes, where they should be given 4.
    Also you can see in the Memory window, that the structs are correct in memory (and I can confirm they function correctly when the code is executed).
    However it appears that Ozone itself is incorrectly interpreting the variables at 8-byte entities rather than 4-byte.
    It seems that the array must have more than 2 elements for the error to occur. It may be because it correctly finds the address for the first and last elements, but not the ones in between.


    Here is my code:

    C Source Code

    1. typedef struct OzoneTest_signed{
    2. int32_t field1[3];
    3. int32_t field2;
    4. } OzoneTest_signed;
    6. typedef struct OzoneTest_unsigned{
    7. uint32_t field1[3];
    8. uint32_t field2;
    9. } OzoneTest_unsigned;
    11. OzoneTest_signed ozone_test_signed;
    12. OzoneTest_unsigned ozone_test_unsigned;
    14. uint8_t set_ozone_test(void){
    15. ozone_test_signed.field1[0]=0x11111111;
    16. ozone_test_signed.field1[1]=0x22222222;
    17. ozone_test_signed.field1[2]=0x33333333;
    18. ozone_test_signed.field2=0x44444444;
    20. ozone_test_unsigned.field1[0]=0x11111111;
    21. ozone_test_unsigned.field1[1]=0x22222222;
    22. ozone_test_unsigned.field1[2]=0x33333333;
    23. ozone_test_unsigned.field2=0x44444444;
    25. //Breakpoint here
    26. return 0;
    27. }
    Display All
    Images

    • ozone_bug.png

      541.23 kB, 2,002×942, viewed 616 times

  • Hi,


    thanks for the inquires.
    Currently data bit fields other than 32 bits can not be displayed correctly.

    This should be fixed in the latest version, V2.40b.
    Could you please give it a try and provide feedback if it works for you?

    Ozone treats a int32_t array inside a struct as an array of 8-byte integers (long long), but it should be 4-byte integers. This makes the variable display of structs incorrect.

    This will be fixed in the next version of Ozone.
    I will update this thread once the new version is available.


    Best regards,
    Niklas
    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,

    Thank you for your reply. I tried this issue with the OZone 2.40c. Latest OZone is better than previous one, but it has still problem for pointer reference.
    I attached two capture screen of OZone (local valiable and global variable). Please check these picture.

    Best regards,
    Masa
    Images

    • Local_Variables.jpg

      282.55 kB, 1,279×1,022, viewed 581 times

    • Global_Variables.jpg

      282.34 kB, 1,290×1,021, viewed 504 times

  • Hi Masa,


    would it be possible for you to provide us with an .elf file which can be used to reproduce the issue?
    This would help us identifying the bug.


    Best regards,
    Niklas
    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 Niklas,

    I can provide the elf file to you. But do you have execution environment ?
    I am using STM32F769NI-DICO board.

    I thought that it was an easily reproducible bug, but is not it?
    Because it only refers to values instead of address lookups.　
    For example compare plu16_test and u16_test in Local_variable.jpg. The Value column of plu16_test is 0x221234,
    but it is correctly 0x1234. The value of Location column is correct as it points to the same address as lu16_test.
    Since the value of the member variables is the value of Location column as the value of plu16_test, the value of
    the Value column is also incorrect (I expect that Location will be the same value as plu16_test).

    Best Regards,
    Masa

  • Hi Masa,


    yes, we have the following eval boards with STM32F769NIH devices here:
    STM32F769 Discovery Kit
    STM32F769I-EVAL

    Best regards,
    Niklas
    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 - Niklas wrote:

    Ozone treats a int32_t array inside a struct as an array of 8-byte integers (long long), but it should be 4-byte integers. This makes the variable display of structs incorrect.

    This will be fixed in the next version of Ozone.
    I will update this thread once the new version is available.


    Best regards,
    Niklas

    Excellent, this test code now works in v2.40c. Thank you for fixing this so quickly!

    Masa, I apologize for hi-jacking your thread! I hope a fix for the bit-field issue comes soon.
    Dan

  • Hi Niklas,


    I attached a set of project files only to solve this problem. This project is a project for the TrueStudio generated by the STM32CubeMX,
    and the operation itself is meaningless. Please use this project file to analyze the problem.
    　By the way, while I tried various build options of this project file, I understood the cause of the problem. The problem only occurred
    when the optimization option was set to "-Og". Therefore, the ELF file of the attached file is generated with "-Og".
    The ELF file is in ”BitFieldTest/TrueSTUDIO/BitFieldTest/Debug/".



    　Because it is an opportunity of a corner, please let me also ask another matter.
    We are currently using the STM32F769I-DISCO board for pre-development until the board on which the STM32F769NI under fabrication
    is completed is completed. I was postponing the question because it is a constraint for this.

    1) I can select STM32F769NI on J-Link or J-Flash device selection screen, but the RAM size displayed at this screen is 240 kB (correctly 512 kB),
    but is there any influence from this?
    2) I use Terminal using SWO with OZone, but there are times when it will not be output. In such a situation, it may become output again by
    starting Terminal->Configure and pressing "OK" button. Is there any condition?
    3) Despite setting Project.SetSWO (1, "4.5 MHz", "200 MHz"), the SWO clock becomes Auto, is this specification?
    4) OZone version is 2.40 or later, there are many cases that most breakpoint markers on the left side of the source code are not attached.
    This happens even if you set the compile option to "-O0", so I continue to use the 2.32 version. Please tell me if there is any information on this matter.

    Best Regards,
    Masa
    Files

    • BitFieldTest.7z

      (870.43 kB, downloaded 517 times, last: )

  • Hi Masa,


    FYI: I forwarded this to the Ozone maintainer.
    Unfortunately, yesterday was a bank holiday in Germany, therefore the investigation will be finished on Monday at the earliest.


    Best regards,
    Niklas
    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 Masa,


    the pointer references issue is resolved in version 2.40d of Ozone.

    Regarding your questions:

    1)
    The RAMSize shown in the device selection is not necessary the size of the RAM available on the target.
    It is the maximum amount of work ram J-Link will use during operations like flash programming.
    On STM32F7 devices, this is the RAM located at 0x20010000 - 0x2004BFFF.
    Therefore from our point of view, everything is working as intended.

    2) 3) 4)
    We would like to investigate this issues.
    Could you please provide me with a data file, a projectfile, and instructions on how to reproduce each issue, which I can forward to the Ozone maintainer?


    Best regards,
    Niklas
    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 Niklas,


    Sorry for slow response.


    > the pointer references issue is resolved in version 2.40d of Ozone.


    The version 2.40d is better than previous one. But it has still problems.
    　　1) For Global Variable is OK.
    2) For Local Valiable is not OK. It is always NULL.
    3) Regarding the same variable name, the variable scope does not seem to work and the address becomes illegal.
    　　 This may be the same problem that OZone can not distinguish static global variables of the same name.


    For your answer,
    1) I understood it just use working ram as tempolariry.
    2) 3)
    I already uploded whole project file[BitFieldTest.7z]. What else is necessary other than that?
    　　When this program is executed, it should show the pointer of the variable in Terminal, but could
    　　you display it without doing anything in your environment?


    4) I tried using version 2.40d, but for now this version seems to have no problem. I do not understand the cause well ..
    　　




    Best regards,
    Masa

  • Hi Niklas,

    I tried OZone 2.42. In this version, I was able to confirm that the display of local variables is as expected.
    And the problem of item number 2), 3) was also fixed.
    However, problems that can not be handled by distinguishing variables of the same name have not been solved.
    The TrueStudio v 7.1.2 can not distinguish it in the same way, but is it difficult to solve this problem?

    It will be helpful if you improve the following points.
    1) If variables with different addresses are the same name, additional data can not be registered in the Watched Data Window.
    2) Please support data display considering variable scope. I think OZone seems to resolve addresses by just variable names without
    considering file names and scopes.
    I think that you understand the problem with repeated questions, but I attached a project I just created to reproduce the problem.
    From the execution result displayed on the terminal, you can see that the program works as intended.

    The point to check is
    a) In this program, I declare local variables with the same names as global variables in lines 151 - 153, but global variables are
    masked with local variables [see attached figure].
    For example, even if you break at the entry of the main function and check the global variable, it is replaced with the address of the local variable.
    Also, we want lines 155 and 156 and lines 158 and 159 to point to different locations, but we will return the same value.

    b) In sub.c and main.c, the u32_tmp is declared as a global variable of the same name(it has a static attribute, so it is effective only in the file).
    The execution result of line 162 is as expected, but OZone can not distinguish between these two variables.

    3) I reported that breakpoints may not be attached after Version 2.40, but it was reproduced also in Version 2.40. I do not know how to cause this problem,
    so I think whether it is necessary to try various things at your company. If this problem occurs, it seems that it will not return to normal unless OZone is
    restarted [see attached figure].
    I use the same elf file, but breakpoints are no longer attached to lines 158 and 162.




    Best Regards,
    Masa

    　
    Images

    • variable_scope1.jpg

      170.02 kB, 1,110×946, viewed 532 times

    • variable_scope2.jpg

      248.54 kB, 1,110×946, viewed 484 times

    • static_global_variable.jpg

      261.96 kB, 1,110×946, viewed 491 times

    • Missing_Breakpoint.jpg

      53.32 kB, 412×402, viewed 480 times

    • Normal_breakpoint.jpg

      45.71 kB, 408×298, viewed 453 times

  • Hi Niklas,

    I could not attach the project file with a previous reply because of the number of files, so I will attach it here.
    As it was the only program to reproduce the problem as before, it is not useful anything else.

    Best regards,
    Masa
    Files

    • BitFieldTest.7z

      (420.51 kB, downloaded 432 times, last: )

  • Hi Masa,


    thanks for testing the new version and for reporting theses issues.
    I forwarded your inquiry to the Ozone maintainer.


    Best regards,
    Niklas
    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.