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.

CCSTUDIO: Issue with armhex output

Thanks Ki.  I got around that single file compile issue via right clicking and selecting 'build selected file(s)'

Also, thanks for the suggestion to use the armhex from command line - that is precisely what I did as well but I am seeing some strange issues.  See the .png attached.  Thanks again for your help.  BTW, we are using a Lauterbach for programming and I really dont know how it interprets the Motorola S3 records.


  • One thing I figured out is the armhex seems to be laying out the S3 records 58 bytes (3A) at a time - so it automatically increments the addresses by 58 when it goes to the next S3 record.  Don't know why it does this.  i discovered this by adding more data to my array to generate more S3 records.  See here below:

  • Hello Anand,

    I split these posts from the original thread and created a new thread. I will bring this thread to the attention of someone with more expertise with armhex.

    Thanks

    ki

  • Please search the TI ARM assembly tools manual for the sub-chapter titled Partitioning Data Into Output Files.  Note that the default ROM width for Motorola format is 8 bits.  You set --memwidth=16.  So, you get two output files.  The file hello.ptp has the even bytes and the auto-generated file hello.m1 (note the warning diagnostic about this file) has the odd bytes (which are always 0).  I'm not sure what you really want to do.  You may need to use --romwidth=16 --memwidth=16.  Or, try --romwidth=32.  

    In the output in your screen shot, the address for the second S3 record is 0x00200100 + (0x1d * 2) = 0x0020013a.  The length of the record is 0x22.  This includes the 5 bytes for the address (4 bytes) and the checksum (1 byte).  So, the length of the data 0x22 - 0x5 = 0x1d.  Because half of the bytes are written to hello.ptp and the other half to hello.m1, the amount added to the address is not 0x1d but (0x1d * 2) = 0x3a.

    Thanks and regards,

    -George