• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 84 subscribers
  • Views 337 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F2800132: help with linker calculated CRC

Manu36
Expert 1360 points
Part Number: TMS320F2800132


Tool/software:

Dear support team.

One part of the code I need to write will be considered as critical and cannot be changed later, the other part can change without issue.

To comply with this, I have created a specific area in flash_bank for thie critical code and then, use the linker to calculate the CRC:

	.section_safety : {sta_tests.obj(.text),
						stl_sp.obj(.text),
						stl_cpu_reg.obj(.text),
						ref_crc.obj(.text) } crc_table(_my_crc_table_for_safety, algorithm=CRC32_PRIME) >FLASHBANK0_SAFETY,	ALIGN(8)

The different .obj are the corresponding file which contains the critical code.

The crc is calculated, the crc check (according to the value saved by the linker) at startup is also OK.

My problem is actually that changing some parts of the code in the non critical part change the value of the CRC.

At the begining I had some function called by the critical code which where in the same flash area than non critical code. So as the adresses affected by the linker were changed in case of code change in the non critical code, this can explain the issue (at this time I can also see that the critical .obj file were changed in case of change in non critical code).

So my first job has been to put all the function which were called by the critical code in the specific flash area or replace the function call by the code of the function. I did'nt change the call to function which were inlined considering that the linker will copy the code in the  critical area.

Now all this job is done and I still have a different CRC in case of change in the non critical area.

I compare the .obj files of the critical part and before and after the change in the non critical part, the obj are identical. In the .lst file, I can only see a difference in date/time.

But I can see that during "build project" one of the critical c file is build even if for me there is no visible reason.

Perhaps there is still a function call which call code in the non critical area but checking the difference in the .map file, it does'nt seems.

Is there something wrong in my understanding? The CRC of the critical area should not change if there is no change in this part right?

What can I used to find wich part of the critical code is affected by the non critical (if any)?

Regards.

  • 0
    TI__Guru**** 250370 points

    I'm sorry I don't fully understand your situation.  But I see you use the section based CRC feature in the linker.  There is also a memory region based way to do it.  It may be more appropriate to your situation.  For details, please search the C28x assembly tools manual for the sub-chapter titled Using the crc() Operator in the MEMORY Directive.

    Thanks and regards,

    -George

  • 0
    Expert 1360 points

    Thank you for the help.

    I will try next week your suggestion. For sure it will be more appropriate but I don't think it will solve the issue.

    In fact my problem is that I don't find why the CRC is affected by a change in other part. I suspect that there is somewhere a call to a function which adress change (or a data which adress change) but the code is quite large and it may be difficult to find where it is.

    My need is to find a tool which can help me to find which part / data / function is changed.

    The best will be a dissasembly with the C code that i can extract and use to make a diff to find where are the difference in the bynary and link this with the code.

    I can probably extract the binary and compare but it will probably be difficult to link it to the C code.

    Regards.

  • 0 in reply to Manu36
    TI__Guru**** 250370 points

    If you are sure the difference is in a function, then adapt the technique described in the article Find Source of Code Size Increase.  That article shows you how to find the functions where code size increases the most.  You are interested in any function with a different size.  One drawback with this approach is it presumes a difference in the code always means a difference in the size.  That is not always true.  It is possible for two functions to have the same size, yet still be different.

    Another approach is to compare the disassembly.  To disassemble the entire program, use a command similar to ...

    dis2000 executable_file.out > disassembly_file.txt

    This default setting only disassembles sections that contain code.  If you want to disassemble the data sections too, add the option --all.  The disassembler is located in the same \bin directory as the compiler cl2000.

    Compare the disassembly for two builds.  Find an address range with lots of differences.  Use the linker map file to associate that address range with 1 or 2 source files.  Then move on from there.

    Thanks and regards,

    -George

  • +1 in reply to George Mock
    Expert 1360 points

    Hello,

    Thank you for sharing some technique. Those are very interesting and will probably help me in the future.

    I finally found my issue using a different technique, instead of calculating a crc for different .obj, I calculated a crc for each .obj. So I have been abble to find which source file has the issue. I was lucky, it was the smallest one so I found easily the issue...