TMS320F28377D: Hex file generation.

Luke,

I'm going to loop in the compiler team to comment.  Today is US holiday, so you should get a reply by tommorow the 6th.

Best,

Matthew

Luke Chen said:

-image

Are you sure image mode is required?  Please learn more about it by searching the C28x assembly tools manual for the sub-chapter titled Image Mode and the --fill Option.  This sub-chapter also explains why the hex file output is so large.  

Luke Chen said:

Is there any known issues of CGT v6.4.6

No.

Luke Chen said:

this situation could be solved when he uses newer version of hex2000 to convert same .out file

The .out file is built with version 6.4.6 tools, then a recent version of hex2000 is used.  Is that correct?  For now, I presume it is correct.  Because of image mode, I don't see why the hex utility output would be any different.

Luke Chen said:

he fails to complete SCI firmware upgrade process because of unreasonable block size data from PC side

This is a constraint imposed by whatever tool uses the hex file created by hex2000.  Please describe this constraint in more detail.  What is the limit?  How is it measured?  

Thanks and regards,

-George

George,

I will check with my customer if he needs image mode.

Regarding this problem, my customer develops one PC utility based on TI SCI flash kernel protocol. In the past, he can upgrade software via SCI boot without problems, so I think there should be no problem with his PC utility.

Recently he modifies software, builds project and converts the .out into .hex for SCI boot, his PC utility detects errors of the .hex file, sometimes is too larger block size(0xEBE2, for example) and sometimes is unreasonable block address(0x232A0A9, for example).

My customer uses CGT v6.4.6 for years and never faces this kind of problem before, he is wondering is there any software coding limitation or any known issues of CGT v6.4.6 causing this error.

According to your feedback, no known issues of CGT v6.4.6(hex2000) causing this kind of problem. Do you think maybe image mode causes this problem please?

Regards,

Luke

Luke,

I'm going to get this re-assigned within the C2000 team, we think there may be some restriction on even aligned addresses, but as George has mentioned that would be a C2000 specific requirement and not the fault of the hex util.  Please give us another day to look into this more.

Best,

Matthew

Luke,

Can you check the customer's linker cmd file to make sure that all the sections mapped to flash are aligned on 128-bit boundary using ALIGN(8)?  This is needed.

In the application's map file, do you see any long section?  If yes, I would suggest to break it down to debug this.

Thanks and regards,

Vamsi

Hi Vamsi,

In my customer's original .cmd file, there is one long flash size definition as below,

FLASH_TEXT        : origin = 0x087000, length = 0x019000

My customer modifies and separates the definition into three smaller ones and seems that fixed this problem,

FLASH_TEXT1      : origin = 0x087000, length = 0x009000

FLASH_TEXT2      : origin = 0x090000, length = 0x008000

FLASH_TEXT3      : origin = 0x098000, length = 0x008000

Does it make sense? Do you think this is the root cause? Please advise, thanks for help.

Regards,

Luke

Vamsi,

I understand, make sure to align the sections on the 128-bit boundary in the .cmd file.

According to Assembly Language Tools User's Guide, length is a 22-bit integer constant. You mentioned that there is a limitation of section length, where can I obtain this information?

If section length is the root cause, how should we explain the reason why my customer never faces this problem before?

Thanks for regards,

Luke

Vamsi,

Where can I get the information of 0xFFFE words limitation please?

Regards,

Luke