Monday, December 11th 2017, 2:23pm UTC+1

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

masa

Beginner

Date of registration: May 10th 2017

Posts: 8

1

Wednesday, May 10th 2017, 9:55am

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


Regards
 masa


danngreen

Beginner

Date of registration: Jun 21st 2016

Posts: 4

2

Friday, June 9th 2017, 7:35pm

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/C++ Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
typedef struct OzoneTest_signed{
	int32_t	field1[3];
	int32_t	field2;
} OzoneTest_signed;

typedef struct OzoneTest_unsigned{
	uint32_t	field1[3];
	uint32_t	field2;
} OzoneTest_unsigned;

OzoneTest_signed ozone_test_signed;
OzoneTest_unsigned ozone_test_unsigned;

uint8_t set_ozone_test(void){
	ozone_test_signed.field1[0]=0x11111111;
	ozone_test_signed.field1[1]=0x22222222;
	ozone_test_signed.field1[2]=0x33333333;
	ozone_test_signed.field2=0x44444444;

	ozone_test_unsigned.field1[0]=0x11111111;
	ozone_test_unsigned.field1[1]=0x22222222;
	ozone_test_unsigned.field1[2]=0x33333333;
	ozone_test_unsigned.field2=0x44444444;

//Breakpoint here
return 0;
}
danngreen has attached the following image:
  • ozone_bug.png

SEGGER - Niklas

Super Moderator

Date of registration: Oct 6th 2014

Posts: 1,691

3

Monday, June 12th 2017, 11:29am

Hi,


thanks for the inquires.

Quoted

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?

Quoted

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
Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
Notification for Embedded Studio: Link

masa

Beginner

Date of registration: May 10th 2017

Posts: 8

4

Tuesday, June 13th 2017, 3:36am

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
masa has attached the following images:
  • Local_Variables.jpg
  • Global_Variables.jpg

SEGGER - Niklas

Super Moderator

Date of registration: Oct 6th 2014

Posts: 1,691

5

Tuesday, June 13th 2017, 11:41am

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
Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
Notification for Embedded Studio: Link

masa

Beginner

Date of registration: May 10th 2017

Posts: 8

6

Tuesday, June 13th 2017, 1:20pm

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

SEGGER - Niklas

Super Moderator

Date of registration: Oct 6th 2014

Posts: 1,691

7

Tuesday, June 13th 2017, 2:17pm

Hi Masa,


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

Best regards,
Niklas
Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
Notification for Embedded Studio: Link

danngreen

Beginner

Date of registration: Jun 21st 2016

Posts: 4

8

Wednesday, June 14th 2017, 2:24am

Quoted

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

masa

Beginner

Date of registration: May 10th 2017

Posts: 8

9

Wednesday, June 14th 2017, 4:53am

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
masa has attached the following file:
  • BitFieldTest.7z (870.43 kB - 61 times downloaded - Last download: Nov 29th 2017, 11:50pm)

SEGGER - Niklas

Super Moderator

Date of registration: Oct 6th 2014

Posts: 1,691

10

Friday, June 16th 2017, 1:23pm

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
Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
Notification for Embedded Studio: Link

SEGGER - Niklas

Super Moderator

Date of registration: Oct 6th 2014

Posts: 1,691

11

Monday, June 19th 2017, 9:54am

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
Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
Notification for Embedded Studio: Link

masa

Beginner

Date of registration: May 10th 2017

Posts: 8

12

Wednesday, June 21st 2017, 12:39pm

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

masa

Beginner

Date of registration: May 10th 2017

Posts: 8

13

Friday, June 23rd 2017, 10:44am

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

 
masa has attached the following images:
  • variable_scope1.jpg
  • variable_scope2.jpg
  • static_global_variable.jpg
  • Missing_Breakpoint.jpg
  • Normal_breakpoint.jpg

masa

Beginner

Date of registration: May 10th 2017

Posts: 8

14

Friday, June 23rd 2017, 10:49am

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
masa has attached the following file:
  • BitFieldTest.7z (420.51 kB - 53 times downloaded - Last download: Dec 4th 2017, 5:00am)

SEGGER - Niklas

Super Moderator

Date of registration: Oct 6th 2014

Posts: 1,691

15

Monday, June 26th 2017, 9:00am

Hi Masa,


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


Best regards,
Niklas
Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
Notification for Embedded Studio: Link