• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 159 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.

CODECOMPOSER: Unexpected behavior of hex2000 binary option

Wolfgang Burger
Prodigy 210 points
Part Number: CODECOMPOSER
Other Parts Discussed in Thread: TMS320F280049C

Tool/software:

Hi all,

we are currently experiencing issues with the generation of binary images for our TMS320F280049C microcontroller firmware. When generating images with the binary option it seems to output a binary which does not contain any fill bytes which makes the binary itself basically useless. I already found some posts regarding this issue with some possible solutions but none of them worked as expected or I just could not get it running like it was described.

One proposed solution was to use tiobj2bin which I found in my code generation tools as a .bat file. When I tried running it with the out file of our firmware it said "C28x files built with --abi=eabi are not supported" because we are using the eabi build. Is there another way to use it in our case or is it just not possible with eabi builds?

Another proposed solution was to use the hex2000 with --binary and --image options. First of all it complained because it requires ROMS directive in --image mode so I tried to find out what I have to add here. After looking through some posts it seemed like I have to add a separate file at the end of the hex2000 command which then contains a ROMS section which states the start address and the length of the image. This is what my file looked like after finding some suggestions in other posts:

Fullscreen
1
2
3
4
ROMS
{
ALL_MEM : origin = 0x83040, length = 0x8000
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The command used for generation was:

Fullscreen
1
hex2000 --memwidth=16 --romwidth=16 --diag_wrap=off --binary --image -o "image.bin" "image.out" ROMS.hex
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Unfortunately it did not work that way due to a syntax error

Fullscreen
1
2
3
ROMS
^
error: syntax error
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Since I did not find an appropriate documentation how I can generate a binary image I wanted to try my luck here. Can anyone tell me about the easiest way to generate a consistent binary image during the build with filled holes? Even with --array mode of hex2000 it seems to be working like it should. Probably it is also easier to generate the binary from a hex file with another external tool. I understand that it is necessary to provide a start address to the conversion due to possible fill at the beginning but for me it does not really make sense to define the length fixed like it is inside the ROMS directive. This would get the build more complicated to reduce the binary size to the minimum length possible when the length needs to be defined inside the ROMS file.

Best regards

Wolfgang

  • 0
    TI__Guru**** 244930 points

    Please follow the directions that appear in this forum post.  To understand the surrounding context, read the entire thread.

    To learn the details on using the hex utility in a CCS project please see the article Hex utility in CCS.  Focus on the last part about how to integrate a hex utility command file into the project.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 210 points

    Hi George, 

    I went through the thread, tried to adjust everything accordingly and tried the same commands and the same arrangement of arguments but the behavior is still the same. It always outputs the message 

    Fullscreen
    1
    2
    3
    ROMS {
    ^
    error: syntax error
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I also attached the file used for the ROMS directive.

    ROMS.txt
    Fullscreen
    1
    2
    3
    ROMS {
    ALL_MEM: o = 0x83040, l = 0x8000
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I tried the hex2000 tools from CCS 12.2.0 (ti-cgt-c2000_22.6.0.LTS) and 10.2.0 (ti-cgt-c2000_20.2.2.LTS). I did not expect any difference but I even executed the tool from windows cmd and powershell but both output the same syntax error message.

    Am I missing something?

    Best regards

    Wolfgang

  • +1 in reply to Wolfgang Burger
    TI__Guru**** 244930 points

    The problem with ROMS.txt is the line endings.  Here is one way to see it ...

    Fullscreen
    1
    2
    3
    4
    % od -c ROMS.txt
    0000000 R O M S { \r A L L _ M E
    0000020 M : o = 0 x 8 3 0 4 0 ,
    0000040 l = 0 x 8 0 0 0 \r } \r
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The command od is available on most Unix systems.  It dumps the file one byte at a time.  The -c option shows characters, or an escape sequence if that byte is not a printable character.  Note \r stands for carriage return, and \n stands for line feed.  Focus on the \r characters.  This is not typical.  In a Windows text file, each line ends with ...

    \r \n

    In a Unix text file, each line ends with ...

    \n

    In ROMS.txt, each line ends with ...

    \r

    I don't know how that happened.  But this is what needs to be fixed.  It is probably best to change the line endings to match the rest of the text files on your system.  That said, the hex utility can handle either line ending.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 210 points

    Hi George,

    wow it is really odd how the file ended up with only carriage return as line endings but I fixed it and it is working now. It first generated only files with fill values but adjusting the addresses to byte addressing helped here.

    Thanks for the help!

    Now I only have to find an easier way to automatically generate the ROMS file that there is no unnecessary padding at the end. It seems like there is no easier way than extracting the information from the map file.

    Best regards

    Wolfgang