MSPM0G3507-Q1: HEX format issue

Hi Huihuang,

Can you provide which IDE and compiler they are using?

Regards,
Luke

Luke,

You just ask question on question!

I don't think you settled my issue!

If you think it is related to IDE or compiler version, can you provide the IDE and compiler version which could settle this issue?

CCS :12.5.0.00007

Compiler :TI Clang v3.2.0. LTS

Hi Huihuang,

I needed the IDE and Compiler because that information is important to determine if it is something we can/do support on current options. For example they could be using GCC instead of TI Clang or IAR/Keil instead of CCS.

Regards,
Luke

Huihuang Chen said:

For current HEX format, the address type is 0x02-- Extended Segment Address Records

I presume you create the hex file with the command tiarmobjcopy.  Is that correct?

Huihuang Chen said:

customer  request is 0x04-- Extended Linear Address Records

The only way to do that is to use the hex utility tiarmhex instead of tiarmobjcopy.  The command to run looks similar to ...

tiarmhex --intel --romwidth=32 -o output_file.hex input_file.out

I don't understand why records with type 0x02 are a problem.  I'd appreciate any explanation.

Thanks and regards,

-George

George,

The reason why type 0x02 are a problem is that , the third party tools protocol which use to read the Hex file is based on 0x04 type. cannot support  the HEX based on 0x02 type. customer last generation MCU  also support 0x04 type. 

Now when use to TI MCU met this 0x02 type issue .

Customer used tiarmhex, the command in CCS as below:

Customer try below command , you can refer to CCS configure as below.

tiarmhex --intel --romwidth=32 -o output_file.hex input_file.out 

The generate HEX not work ,because the romwidth = 32 changed the data order.

Customer requirements is generate the HEX based on 0x04 -- Extended Linear Address Records under " memwidth=8 --romwidth=8 "  condition.

Please provide the solution.

Huihuang Chen said:

Customer requirements is generate the HEX based on 0x04 -- Extended Linear Address Records under " memwidth=8 --romwidth=8 "  condition.

The settings --memwidth=8 --romwidth=8 --intel will work as required.

Huihuang Chen said:

the third party tools protocol which use to read the Hex file is based on 0x04 type. cannot support  the HEX based on 0x02 type.

Then this third party tool should be fixed to handle the 0x02 type.  But I suspect that is not a practical alternative in the short term.

Thanks and regards,

-George

For " The settings --memwidth=8 --romwidth=8 --intel will work as required ". 

I don't understand what your means, with " --memwidth=8 --romwidth=8 --intel " command line, why you said will work as required? did you try this command before and can get 0x02 type HEX?

Actually test result are:    with " --memwidth=8 --romwidth=8 --intel " command line, the generated HEX is based on 0x02 type, while customer required the HEX format is 0x04 type.

A command similar to ...

tiarmhex --intel --romwidth=8 --memwidth=8 -o output_file.hex input_file.out

... creates a hex output file that uses 0x04 type records, and not 0x02 type records.

Thanks and regards,

-George

George,

Confirmed the Hex file generate with command : tiarmhex --intel --romwidth=8 --memwidth=8 -o output_file.hex input_file.out, could generate 0x04 type 

records.

But this hex still cannot met customer requirement because the HEX file first line didn't include 0x04 -- extended Linear Address info.

Based on third party requirement, the first line need to  with 0x04 -- extended Linear Address info.

For MSPM0G3507 case, the first line should be :020000040000FA.

Could you help provide the solution?