• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 449 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F280025: S19 question

Huihuang Chen
Expert 4010 points
Part Number: TMS320F280025

Hi Champ,

Customer  try to generate S19 format in CCS. And get the S19 content like following, that means the byte count is 0x22.

Customer want generate the S19 file which byte count is 0x25, could you advise the it is possible or not?

S00600004844521B
S30700080000489315
S32200082000064442A830180D46224644C41A8606024141E1820604411F80424100C7B5
S3220008201D43220522A942A943013BC4CC1A840604411F80424100C74322052243A91F
S3220008203A42A9013B55C4CC1A8406024200000001A942390000A942340000A9422F29
S322000820570000A9422A0000A942250000A942200000A9421B0000A942160000A9423C

  • 0
    TI__Guru**** 244720 points
    Huihuang Chen said:
    Customer want generate the S19 file which byte count is 0x25

    Unfortunately, it is not possible to control the number of of bytes per line in the hex utility output.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Expert 4010 points

    George,

    TMS570 could generate S19 file with 0x25 byte count .

    Any way to generate S19 file with  0x25 byte count  for C2000?

    Customer use ETAS INCA tools for calibration, in this tools the S19 data bytes  just support  10 or 16  or 20 or 32 or  64.

    If byte count is 0x25  that means data bytes is 32 per line. 

    if it is impossible to control the number of of bytes per line in the hex utility output for C2000. That means ETAS INCA tools cannot support C2000 device.

  • 0 in reply to Huihuang Chen
    TI__Guru**** 244720 points

    When I try a simple example, I get S3 records with a byte count of 0x25.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    C:\examples>type stub.c
    int main() {}
    C:\examples>cl2000 stub.c -z -o stub.out
    <Linking>
    C:\examples>hex2000 -m3 --romwidth=32 -o stub_hex.m3 stub.out
    Translating to Motorola-S3 format...
    "stub.out" .text ==> .text
    "stub.out" .cinit ==> .cinit
    "stub.out" .reset ==> .reset
    C:\examples>more stub_hex.m3
    S00600004844521B
    S3250000004028AD0000FF69561F5616561A2940761F00002902761B76400118520061427622F6
    S3250000005028A9011D28A800000901611B76C0011D29046F0F9B0024A9DF016C04290424A895
    S32500000060DF011EA6F7A1248606A781A109011EA724A96303FF5C3B0459A9DF010009FFEC53
    ...
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I don't know how you get a byte count of 0x22.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 244720 points

    Sorry, but I made an error in my last post.  I used --romwidth=32.  You probably use --romwidth=16.  When I use that, I get a byte count of 0x23.  But I think we have found a possible solution.  Try changing to --romwidth=32.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Expert 4010 points

    George,

    I just let romwidth as default , like following , so get 0x22.

    "C:/ti/ti-cgt-c2000_20.8.0.STS/bin/hex2000" --diag_wrap=off --motorola=3 -o "epwm_ex1_trip_zone.S19"  "epwm_ex1_trip_zone.out" .

    Are you sure,  we can set --romwidth=32 for C2000 device?

  • 0 in reply to Huihuang Chen
    TI__Guru**** 161605 points

    Huihuang,

    George is out today and will be back in the office tomorrow.

    Regards,

    John

  • 0 in reply to Huihuang Chen
    TI__Guru**** 244720 points

    There is a problem with the command ...

    Huihuang Chen said:
    "C:/ti/ti-cgt-c2000_20.8.0.STS/bin/hex2000" --diag_wrap=off --motorola=3 -o "epwm_ex1_trip_zone.S19"  "epwm_ex1_trip_zone.out" .

    When --motorola=3 is used, the default --romwidth=8 and default --memwidth=16.  This means you get two output files, one more in addition to epwm_ex1_trip_zone.S19.  One file has the high bytes, and the other has the low bytes.  For more details, please search the C28x assembly tools manual for the sub-chapter titled Partitioning Data Into Output Files.  You should see a diagnostic similar to ...

    Fullscreen
    1
    warning: Data is being written to auto-generated file file.m01
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The typical fix is to add --romwidth that equals the default --memwidth.  In the case of C28x systems, that means --romwidth=16.  That produces a file that meets the specifications of Motorola S3 format.  However, the length of each line is 15 16-bit words, which you see on each line as 0x23.  

    You can get a length on each line of 0x25 by using --romwidth=32.  The generated file also meets the specifications of Motorola S3 format.  

    Unfortunately, I do not know why changing --romwidth changes the length of each line.  I'll have to get back to you on that.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 244720 points

    Please understand that the specification of Motorola S3 format does not require that one line of output be a specific length.  Different lengths are allowed.  For details, please search the C28x assembly tools manual for the sub-chapter titled Motorola Exorciser Object Format.  

    It turns out there is a loose, unintentional, relationship between --romwidth and the length of one line of output.  As we have seen, --romwidth=16 emits lines of length 0x23 and --romwidth=32 emits line of length 0x25.  Either length meets the requirements of the specification.  While this is unlikely to change in future releases of hex2000, because it is not a strictly defined part of the specification, a change is possible.  Generally speaking, the best course is for the tool that reads the hex file to be flexible regarding the length of each line.

    Thanks and regards,

    -George