Array type variables, that contain "_" as array index prefix are not updated

[Ahelion]

I have a a2l generated with canape(from vector) and I tried to update with this tool. The canape tool generates individual characteristics for each element of the variable example_array[3] example_array0 example_array1 example_array2 Normal variables are updated, but variables that are arrays: are not updated. They all have in the output a2l the value 0 for address(as if it did not find the variable name).

[DanielT]

Hi, Thanks for the report.

It looks like there might be different handling in different versions of canape. The code already has a special case for arrays that are created with names like examplearray._0\ (note the extra dot in the middle), looks like I will need to extend that to work without the dot.

[Ahelion]

Hello again, Now I saw I made an error in the ticket: Please see here an example:

Original a2l /begin CHARACTERISTIC aLightFcnStat._91_.Active_Cnt "" VALUE **0x800FED4** __UBYTE_S 0 NO_COMPU_METHOD 0 255 Generated a2l file from elf that contains this array/struct thing /begin CHARACTERISTIC aLightFcnStat._91_.Active_Cnt "" VALUE **0x0** __UBYTE_S 0 NO_COMPU_METHOD 0 255 The variable does exist in the code. Btw, don't feel bad for this, but vectors own tool(not canape) does not actually update it correctly, that is why I wanted to give a look to your tool.

[DanielT]

So, I have some questions: The names that should be resolved don't have "_0_" after all, but rather ".0." (or ".91." in your example)? Also: does this characteristic have a SYMBOL_LINK?

The lines in your example only show the characteristic name. That is used as a fallback to try to find the original symbol, but in reality the characteristic name is allowed to be anything. You could call the characteristic my_awesome_value, but link to a variable "boring_value" using SYMBOL_LINK.

My concern here is that I expect SYMBOL_LINK to work correctly for any existing symbol. When resolving variables using the characteristic name, maybe there could be an extra fallback, but in the end there is no way to cover every case, because the name is fundamentally free-form.

[DanielT]

I just saw that you updated your comment. It seems the only difference between the two example lines you posted is in the address. The array indexing looks ordinary, using "._91_.", which is supported. If you have a SYMBOL_LINK section or an IF_DATA CANAPE_EXT section, then either of those would take priority over using the characteristic name. If either of them is present but wrong, then that would explain why it doesn't work.

Preferably I would like to see the full characteristic definition up to /end CHARACTERISTIC.

[Ahelion]

Hello Daniel, Thank you for responding so fast. Here is the full thing /begin CHARACTERISTIC aLightFcnStat._91_.Active_Cnt "" VALUE 0x800FED4 __UBYTE_S 0 NO_COMPU_METHOD 0 255 EXTENDED_LIMITS 0 255 FORMAT "%.15" /begin IF_DATA CANAPE_EXT 100 LINK_MAP "aLightFcnStat._91_.Active_Cnt" 0x800FED4 0 0 0 1 0x87 0 DISPLAY 0x0 0 255 /end IF_DATA SYMBOL_LINK "aLightFcnStat._91_.Active_Cnt" 0 ECU_ADDRESS_EXTENSION 0x0 /end CHARACTERISTIC had to change it, git changed the formating

[DanielT]

Well, I've tested this and it works for me.

I added this code to a file and compiled it:

typedef struct {
    uint8 Dummy_a;
    uint8 Active_Cnt;
    uint8 Dummy_b;
} teststruct;
const teststruct aLightFcnStat[100] = {0};

Then I added your CHARACTERISTIC definition to an a2l file and updated it. The address after updating was set to a reasonable value (in particular: not zero). Is the C code significantly different from my test code?

Maybe there is something strange happening in the debug info of your elf file. Can you inspect that variable using a debugger?

[Ahelion]

Dumb question: can the tool also generate a a2l file directly? I will test again tomorrow, on a different laptop now, but I wask thinking of how the problem is when updating? Can the tool just simply generate an a2l file, containing all variables(even if it would take forever and one year)?. or specify it module name(c files, that it should look for)?

[DanielT]

Well, it can generate a new a2l file now - I just pushed release 1.0.1

You could get that and try this: a2ltool --create --elffile yourfile.elf --insert-characteristic aLightFcnStat._91_.Active_Cnt --output outputname.a2l

That should create a new a2l file containing only your "problem characteristic".

[Ahelion]

Hello again. I ran an update and got this: And when I did a create, i got this:

Now, maybe the problem is with the elf file :( it was made with the green hills compiler for arm. I can not attach the original one, but I can give you a link to a ticket I opened with renode, there also I have issues loading the elf file: https://github.com/renode/renode/issues/257#issuecomment-957712931.

[DanielT]

I've attached a test version I'd like you to try.

In this build I have made two changes:

• first of all it will print an error message giving details every time it fails to load variable or type info from the debug data
• secondly, I spent some time looking at the elf file you attached to the renode issue you mentioned above. It seems that the Geenhills compiler you're using doesn't add an "upper bound" attribute to the debug info for arrays. Rather than treating this missing attribute as a reason to discard the info, this build will simply derive the upper bound by calculating total_size / element_size

a2ltool-test-version.zip

It is possible that the second change will already fix your problem. If it doesn't, then please run the software with "--verbose" and check if there are any error messages.

[Ahelion]

Hello, Please can you put it in a branch? On my work PC, the IT people activated all sorts of antiviruses that go crazy even at the sound of a zip file from the internet. I can re-compile it, I have a rust compiler and cargo, the works. Thank you for your patience.

[DanielT]

Right, that makes sense. Companies that allow arbitrary binaries end up as ransomware victims sooner or later.

I've cleaned up the code a put it on the dwarf_reader_enhancements branch. I'm fairly happy with it as it is and will likely merge after taking another look at it tomorrow. Nonetheless it would be good to hear if it solves your problem.

[Ahelion]

Everything seems to work. Your tool seems to be a good tool(from the branch), everything is generating ok. I will test in on real HW these days. I tip my hat to you sir! You are a real professional.