• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 156 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.

TMS320F28388S: armhex utility does not handle sections > 0xFFFF bytes

Scott Mayne
Prodigy 40 points
Part Number: TMS320F28388S

The armhex utility apparently does not handle linker sections greater that 0xFFFF bytes. When I have .text that exceeds that size the size saturates to 0xFFFF and all the data for the section is included. The result is a hex file that cannot be parsed.

No warnings are given by armhex and I haven't found an option that properly splits the section.

Here are the relevant lines from my 

CM linker file:

MEMORY
{
FIRMWARE : origin = 0x00204020, length = 0x0003BFD0
}

SECTIONS
{
.text : > FIRMWARE, PALIGN(16)
}

Map output file:
.text 0 00204020 00010340

armhex arguments:

"C:/ti/ccs1260/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/bin/armhex" --memwidth=8 --romwidth=8 --diag_wrap=off --ascii -o "cm.hex"  "cm.out"

When I then try to parse the hex file output:
Block Address: 0x204020; Length: 0xFFFF

Parsing for following blocks then fails because the length value in the hex file was truncated but the entire 0x10340 bytes of data are present in the hex file.

I have also tried splitting the FIRMWARE memory into 0xFFF0 sized chunks, but that does not allow the usage of PALIGN which causes other alignment/fill issues

    .text       : >> FIRMWARE | FIRMWARE1 | FIRMWARE2 | FIRMWARE3, PALIGN(16)
The closest thing I've found that works is to define another section and put a subset of the .text in that section to bring it under 0xFFFF bytes.
Is there a better solution?
  • 0
    TI__Guru**** 239295 points

    From the command ...

    Scott Mayne said:
    "C:/ti/ccs1260/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/bin/armhex" --memwidth=8 --romwidth=8 --diag_wrap=off --ascii -o "cm.hex"  "cm.out"

    ... I see you use ASCII output format.  To see the details of that format, please search the TI ARM assembly tools manual for the sub-chapter titled ASCII-Hex Object Format. The length of the data is not explicitly part of the format.  Rather, the length is implied by the amount of data associated with an address.  Thus, I don't understand how this ...

    Scott Mayne said:
    When I then try to parse the hex file output:
    Block Address: 0x204020; Length: 0xFFFF

    ... happens.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 40 points

    The format of the data payload in the hex output is specified in table 12-4 from the TI ARM assembly tools manual, which is made up of a list of data blocks. The total length of the data is not what I have a problem with, as I can read the length of the file. Parsing the lengths of the individual blocks is the issue that I have.

    I am parsing the payload correctly from this format, except when there are sections from the linker that require more than 2 bytes to specify the size.

    For my example there is a block with a size (nl) of 0x10340. The block header saturates the block size (nl) to 0xFFFF but then includes the unsaturated nl (0x10340) bytes of raw data for that block. This leads to a hex file that cannot be parsed because the reader of this file does not know that there were actually 0x10340 bytes before the next block header. This is what I need a solution for.

  • 0 in reply to Scott Mayne
    Prodigy 40 points

    I found my answer. The 20.2.7 armhex has a new --boot_block_size argument that was not supported by the 20.2.6 version.

    "C:/ti/ccs1260/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/bin/armhex" -boot -gpio8 --boot_block_size=0xfff0 -a -o "cm.hex"  "cm.out"