TMS320F28075: HEX2000 16bit generation

I cannot test this solution to be certain it works.  But I am confident enough to ask you to try it.

Add the hex utility option --romwidth=16.

To understand why, please search the C28x assembly tools manual for the sub-chapter titled Partitioning Data Into Output Files.  Understand the effect of --romwidth, and that for Motorola output format, the default is --romwidth=8.  Because --memwidth=16 and --romwidth=8, that means there are two output files, one for even bytes and one for odd bytes.  I doubt that is correct for your system.

Please let me know if this suggestion resolves the problem.

Thanks and regards,

-George

Hello,

She used the blinky project from the driver_support examples to test for the build. Do you know of a different method for merging the two files into one?

Regards, Holger

I'm not familiar with the utility srec_info.  I suspect it presumes memory is 8-bit byte addressable.  This is not the case with C28x CPU, or the address part of the records produced by hex2000 when --motorola=3 is used.  In that case, each address corresponds to a 16-bit wide word.  Is there a setting in srec_info which can be configured to account for this difference?

Thanks and regards,

-George

Hello George,

Yes, there are settings in the options for this tool (srec_cat, srec_info, srec_cmp). She used this in the "srec_cat -unsplit" to generate one from the two with hex2000 -romwidth=8 S-Record files. The tool generates an S-Record file in which the 16-bit words are assembled correctly, but unfortunately the addresses of both files are added to one address.

(S-Record file with srec_cat unsplit (addresses are added but the 16bit words are assembled correctly))

She tried with the most different attitudes, but unfortunately without success. Her guess is that the line length of the generated S-Record file at hex2000 --romwidth=16 is causing problems. This is odd.

(S-Record file with hex2000 --romwidth=16)

As soon as the line length is straight, srec_info no longer returns any error messages and also her client's tool reads the file.

But unfortunately, she hasn't found a way to convert this S-Record file to a different line length.

Srec_cat can do this in principle, but it gives her an error message and with the hex2000 tool she don't find a way to set the line length.

Regards, Holger

I have to admit I am confused as to what the customer wants to do.  I have yet to see anything to suggest hex2000 has done something different than how it is documented to work.

Many details of hex2000 output are not specified.  Among such details is the amount of data on one line.  It turns out most lines have 15 16-bit words (30 8-bit bytes) of data.  In one S3 Motorola format record, the byte count is the number of 8-bit bytes on the line, not counting the S3 and byte count itself.  On a typical line there are ...

• 4 bytes of address
• 30 bytes of data
• 1 byte of checksum

This totals to 35 bytes, or 0x23 in decimal.  That is why many lines begin S323.  I don't understand why 0x23 bytes causes a problem, but it apparently does.  

HS FAE Germany said:

with the hex2000 tool she don't find a way to set the line length.

Unfortunately, there is no method for controlling the amount of data in one line of output.

How do you account for the fact the address in the S3 record corresponds to the location of a 16-bit word, and not an 8-bit byte?

Here is a completely different suggestion to consider.  I think srec_info, or one of the other related tools, can read in a binary file and convert it to a Motorola format hex file.  If that is correct, use hex2000 with the --binary option to create a binary file, then convert it to a Motorola hex file.  Then you can use srec_info to format the address, byte counts, line length, etc. as needed.

Thanks and regards,

-George