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.

TMS320F28075: HEX2000 16bit generation

Part Number: TMS320F28075

Hello,
customer uses CCS 10.3.1.00003 and CTG 20.2.5.

Customer has some problems to generate a boot loader with HEX2000 tool with following configuration to generate S-record file:

1 . Generation of S-Record file

With the current status, an S-Record file can be written to flash, but when jumping into the application it jumped to ILLEGAL ISR(). In order to identify possible differences, we have created and compared 2 memory dump files. Once from the original blinky project and once from the boot loader after flashing the S-Record file. Memory dump can be set to multiple settings, including 8-bit and 16-bit. The high byte is missing for the 8-bit display


Original Blinky 16-Bit Memory

Original Blinky 8-Bit Memory

The 8-bit memory dump comparison is the same, but the 16-bit memory dump comparison is not. However, the S-Record file only returns the data of the 8-bit memory dump.

Are there any other HEX2000 options/settings that need to be used?

Regards, Holger
  • 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,

    customer still has problems with the generation of the S-Record file. If she set -romwidth=8, she get two S-Record files, as you mentioned. However, end customer's PC firmware only allows one S-Record file. She tried to merge the two files into one using the srec_cat srecord.sourceforge.net/ tool, but the -unsplit option adds the addresses of the two files.

    If she generate an S-Record file with -romwidth=16, then something with the file does not seem to be OK. Both her customer's firmware and srec_cat or srec_info report an error.

    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.  

    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