• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 79 subscribers
  • Views 2932 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Hex file too large while IAR download works fine

Stuart Truax
Prodigy 90 points
Other Parts Discussed in Thread: Z-STACK, CC2530

Dear Community,

          I have modified the GenericApp program in the Z-stack 2.4.0-1.4.0 example projects directory to do some high-frequency bit-banging on the I/O ports. To do this, I had to write a lot of fast low-level code. 

         I can download the program onto a CC2530F256 (256k flash memory) using IAR's "Download and Debug" function with no problem. However, when I compile to hex and download using the flash programmer, the resulting file exceeds the chips flash memory size! I have used the same stack/heap sizes and code/data models as the example GenericApp project.

             What is the disconnect here? The IAR-downloaded code works perfectly well when I reset the chip and let it run without a serial cable attached, so the code must somehow fit.  Any ideas why the hex file can't? Thanks.

 

SensorGuy

 

  • 0
    TI__Genius 9990 points

    SensorGuy,

    What software are you using to try and program the flash using the binary HEX file?

     

    Gustavo

  • 0
    TI__Genius 9990 points

    SensorGuy,

     

    IAR natively creates d43 files in debug mode. Are you taking that same file and converting it to HEX or are you compiling using Release or another mode where the settings (such as optimization) might be different?

     

    Gustavo

  • 0 in reply to Gustavo L
    Prodigy 90 points

    Gustavo,

         I am using the TI SmartRF Flash Programmer for the programming. The hex files are generated in the IAR linker by specifying an intel-extended output with .hex extension. I think the C-SPY debug info is automatically turned off when I do this (?). Thanks.

    P.S. I had to use "high" optimization for speed for my I/O code to talk to my sensor and meet timing constraints.

     

     

     

  • 0
    Guru 227245 points

    SensorGuy said:
    the resulting file exceeds the chips flash memory size

    How do you determine that?

    By file size it won't work. The HEX format requires two bytes readable 'HEX' values for each binary byte, plus checksum, address info etc. So the file size can easily be as large as three times the plain code size.

    There's another possible problem: the hex file specification does not support >64k address space. So after writing 0xffff, the addressing begins with 0x0000 again (but needs to be written to 0x10000). If the programming software does not know and support this, it might incorrectly issue an error.

    The Elprotronic software works fine.

  • 0
    TI__Genius 9990 points

    Could you try a TI-TXT file as output? Even a d43 might be a good thing to try.

     

    Gustavo

  • 0 in reply to Jens-Michael Gross
    Prodigy 90 points

    Jens-Michael Gross said:

    the resulting file exceeds the chips flash memory size

    How do you determine that?

    [/quote]

    Jens-Michael ,

    The SmartRF Flash Programmer gives me the following error: "CC2530 - ID5940: HEX file content at address 0x491B0 exceeds chip's 256 kB flash size".

    Thanks for the response.

  • 0 in reply to Stuart Truax
    Guru 227245 points

    Stuart Truax said:
    HEX file content at address 0x491B0 exceeds chip's 256 kB flash size

    Well, that's of course too big. There shouldn't be any content @0x491b0. It looks like the software is interpreting the file wrongly. Either the file format is not compatible with what the software expects ur it completely chokes on the 16 bit addressing overflow.

    There are different HEx formats: TI hex file and Intel hex file. Both differ in the way the addresses are defined and in the notation of line/file checksums. If a checksum is interpreted as address, well, any type of error can occur :)

**Attention** This is a public forum