TMS320F280039C: HEX generated from CCS and HEX read out from Uniflash appear different

Hi Wayne,

Is it about the erased locations' values 0xFFFF in the output from the UniFlash?

Or the endianness?

Thanks and regards,
Vamsi

Dear Vamsi,

I think 0xFFFF is related, but I am not sure if some others are related.

For example, this is from Uniflash.

This is the original HEX from CCS.

In fact, I have compared the checksum generated by CCS and the checksum read out by Uniflash and they are same.

But the user wants to use another HEX editor to confirm.

That is, by a third party tool to confirm this redundantly to ensure they are same.

Dear Wayne,

To me, it looks like the erase words are all downloaded since the download from Uniflash includes all of the locations in the given memory range.

I will assign this to our UniFlash team to help you further (I will be out of office for a week).

Thanks and regards,
Vamsi

Dear Vamsi,

I think so too.

Therefore, would you please ask CCS or Uniflash team to clarify this.

Is there any option in CCS HEX generation that can be used to generate the same Intel HEX as what Uniflash does?

Wayne Huang

Vamsi Gudivada said:

To me, it looks like the erase words are all downloaded since the download from Uniflash includes all of the locations in the given memory range.

Agreed. UniFlash would dump the entire memory contents vs the original hex file only having the actual data.

The reply by Ki is partially correct.  There is more to it.  

In the same document referenced by Ki, search for the sub-chapter titled Image Mode and the --fill Option .  Learn how to put a ROMS directive in a command file.  That ROMS directive will describe the memory range of interest (probably all of flash).  Use image mode and the --fill option.

A different solution to consider ...  Read this forum post, and the rest of the thread.  That shows how to change the linker command file to fill the memory range(s) that correspond to flash.

Please understand that, while I am confident these solutions will work, I cannot guarantee it.  The output of the hex utility hex2000, and the dump feature of UniFlash, are not designed or tested to match each other.  That we can find a way to make that work is an unintended feature.  

Thanks and regards,

-George

Dear Ki, George,

Would you please test it and confirm us first because these tools CCS hex untility/Uniflash are both from your team?

I think only the authors of CCS hex utility/Uniflash know how these HEX files are generated.

Wayne Huang

Hi Wayne,

Wayne Huang said:

Would you please test it and confirm us first because these tools CCS hex untility/Uniflash are both from your team?

I'm not quite sure what you wish for us to test. As George mentioned, you typically do not compare hex files where one is basically a memory dump and the other generated from the build tools. Both the UniFlash memory dump functionality and the Hex Conversion Utility are tested separately to ensure validity and accuracy.

On a side note, the Hex Conversion Utility that CCS uses to generate the hex file is from a different team (Compiler team) than the one which creates UniFlash (CCS team).

Thanks

ki

Ki said:

I'm not quite sure what you wish for us to test

Ok I believe you were referring to George's workaround in his last post. If the customer can provide his project to us, we can take a look.

Thanks

ki

Please also have the customer provide his hex file from UniFlash. You can send by E2E provate message if you do not wish to post publicly.

Dear Ki,

The user is confused why this is related to their project because this should be independent of a project usage.

Would you please just use a simple TI example like below to show this?

C:\ti\c2000\C2000Ware_4_01_00_00\driverlib\f28003x\examples\led\led_ex1_blinky.c 

This is the HEX utility parameters they use.

--memwidth=16 --romwidth=16 --diag_wrap=off --intel

Or do you think if there is anything specific you want to know first?

Wayne Huang

Wayne Huang said:

Or do you think if there is anything specific you want to know first?

We cannot guarantee that a solution will work for the customer's specific use case unless we have the example that the customer is using. As George mentioned, what the customer is trying to do is an unsupported use case. We do not want to run into a case where it works for a simple blinky example but when the customer tries it on their actual project, the results are less than anticipated.

Otherwise, the customer can try the steps mentioned by George and see if it works for them.

Thanks

ki

Dear Ki,

Let me clarify.

Do you mean the method you proposed may be just a workaround for a specific project rather than a systematic way to guarantee that all projects work?

Wayne Huang

Wayne Huang said:

Do you mean the method you proposed may be just a workaround for a specific project rather than a systematic way to guarantee that all projects work?

We cannot guarantee anything because the customer is trying to use the tools for a purpose that they were not designed for. As George mentioned, it *should* work. But again this is not a use case that we have tested or investigated. Hence no guarantees.