Tuesday, June 27th 2017, 4:05am UTC+2

You are not logged in.

  • Login
  • Register

Reply

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.

Message information
Message
Settings
Automatically converts internet addresses into links by adding [url] and [/url] around them.
Smiley code in your message such as :) is automatically displayed as image.
You can use BBCode to format your message, if this option is enabled.
Security measure

Please enter the letters that are shown in the picture below (without spaces, and upper or lower case can be used).

The last 10 posts

Yesterday, 9:00am

by SEGGER - Niklas

Hi Masa,


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


Best regards,
Niklas

Friday, June 23rd 2017, 10:49am

by masa

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 - 5 times downloaded - Last download: Yesterday, 3:07pm)

Friday, June 23rd 2017, 10:44am

by 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

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

Wednesday, June 21st 2017, 12:39pm

by masa

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

Monday, June 19th 2017, 9:54am

by SEGGER - Niklas

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

Friday, June 16th 2017, 1:23pm

by SEGGER - Niklas

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

Wednesday, June 14th 2017, 4:53am

by masa

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 - 14 times downloaded - Last download: Today, 2:16am)

Wednesday, June 14th 2017, 2:24am

by danngreen

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

Tuesday, June 13th 2017, 2:17pm

by SEGGER - Niklas

Hi Masa,


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

Best regards,
Niklas

Tuesday, June 13th 2017, 1:20pm

by masa

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