We found that from version 2.0 of Freemaster all ELF files are not correctly interpreted (MPA files options -> Binary ELF with DWARF2/DWARF4 dbg format) used with different NXP MCU.
Whenever an array of variables or an array of structures is present in the ELF file only the first record is interpreted
(AAA [0]) while others are missing (AAA [1], AAA [2], ...).
Also from version 1.4 of Freemaster the arrays of simple variables (es. int BBB[10]) if generated have the size of the single variables set to 0 in the "size" field.
In the Freemaster version 1.3 the single variables of the array of simple variables (es. int BBB[10]) had the right size set to 2!
Thanks for the support
Hello,
FreeMASTER 3.0 has just been released at www.nxp.com/freemaster. Please see the release announcement and give a try to new array-member-variable generator feature as discussed above.
In the Generate Variables dialog, select the symbol representing the first array element:
Press the Create array-element variables button and select range of variables to generate
This approach works well also with arrays of arrays and similar complex types. Just be careful and avoid creating large number of variables as the performance of the UI may be degraded. Accessing the memory using a symbol expression directly from a custom JavaScript code behind a Control Page may be a good alternative to creating large number of variable objects to be shown in Variable Watch view.
Please use the new community page to raise other issues you might face with the FreeMASTER 3.0.
Thank you,
Michal
Hello,
I have the same problem with the actual Freemaster version (2.5.13.0). Only the first array element is shown in Freemaster.
NXP please fix that issue.
Hello,
although it may seem as a bug in FreeMASTER 2.x, this behavior is intentional. For any array type, only the first array member is made available as a “named” symbol. This change was made to limit number of named symbols in the project to speed up the ELF processing, sorting and to simplify symbol lookup in the drop-down lists. When dealing with MCU applications with a large number of arrays with many elements, the list of named symbols has quickly grown beyond reasonable limits. Accessing any array element is still possible though. The address entry in FreeMASTER variable definition dialog is actually able to evaluate the address properly even if element index is higher than zero. You need to type the element index manually.
For example, having a symbol int arr[10]; the two named symbols are registered in the project: arr and arr[0]. When defining a FreeMASTER variable manually, you can specify any element index in the address field: for example arr[1], arr[2] etc. The element address will be resolved properly. BTW: The zero-size bug of version 1.4 should be resolved in 2.x versions.
I understand that having a named symbol for the first array element only presents an issue when mass-generating the variables using the “Generate” tool. The Generate dialog is going to be extended in the upcoming release. It will enable simpler mass-generating variables for array elements from selected range of indices.
Best regards,
Michal
Hello,
finally some interesting answers.I can understand the reasoning and the choice made. But if we extend the reasoning to aray of data structures it is practically impossible to manage the generation of the same in a simple and effective way!
I hope something changes in the cited "upcoming release".
Thanks
Marco
To help to find a solution, I add the following information:
I enclose a small project based on DSC56F8345, IDE Codewarrior 8.1 to facilitate the work of those who want to solve the problem
Thank you
Marco
Hi Pat,
I confirm that the only solution is to use the manual creation for the array. But compared to before it is very inconvenient especially with arrays of structures!
Unfortunately none of NXP has ever answered me or found a solution, I don't think it is a BUG too complicated, just use the ELF parser function used in the Freemaster version 1.3!
Best regards,
Marco
Good morning,
just over three months have passed, I updated Freemaster to version 2.0.9 but the problems with the ELF parser despite the bug fixing mentioned in the change log persist!
NXP can you fix this BUG?
Hi Marco,
I have the same issue with Freemaster 2.0.9 and GHS compiler 2018.5.4. As workaround I create manually the array variables.
b55689 Do you know if Freemaster's development engineers are aware about this issue ? I attached the ELF output file.
Best regards,
Pat