Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 490 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.

UNIFLASH / C2000 HEX File Format Compatibility

Kier
Mastermind 7510 points
Other Parts Discussed in Thread: UNIFLASH

Hello,

By experiment, it seems that for a C2000 device, UNIFLASH can only interpret HEX files (for flashing and verification) where romwidth=16. Is that correct please?

e.g. The address field is incremented by just 0x10 for 0x20 octets as opposed to the usual 0x20 for 0x20 octets?

Thank you.

  • 0
    TI__Guru**** 437581 points

    I know that romwidth=16 is typically recommended for C2000 devices. That is about the extent of my knowledge in this area. I am following up with UniFlash engineering for more details.

    Thanks

    ki

  • 0 in reply to Ki
    TI__Guru**** 437581 points
    Kier said:
    By experiment, it seems that for a C2000 device, UNIFLASH can only interpret HEX files (for flashing and verification) where romwidth=16. Is that correct please?

    The UniFlash program loader should be able to handle different romwidth types

    Kier said:

    e.g. The address field is incremented by just 0x10 for 0x20 octets as opposed to the usual 0x20 for 0x20 octets?

    The above example looks like correct behavior. Is that the romwidth=16 case?

    Thanks

    ki

  • 0 in reply to Ki
    Mastermind 7510 points
    Ki said:
    The above example looks like correct behavior. Is that the romwidth=16 case?

    Yes, that's right. romwidth=16. The NP++ example is a file made by hex2000 with romwidth=16. If I upload the same segment with UniFlash and export, I get exactly the same file. Therefore I infer that UniFlash must use romwidth=16 internally, at least by default.

    Ki said:
    The UniFlash program loader should be able to handle different romwidth types

    I would have thought so too but I can't see how. Certainly I can't see how UniFlash can infer a different romwidth just from the contents of the HEX file alone and I can't see a romwidth GUI setting. So this is why I assert that UniFlash expects romwidth=16 and cannot correctly flash a hex file into a C2000 with a different romwidth hex file.

  • +1 in reply to Kier
    TI__Genius 11995 points

    Kier,

    Kier said:
    Yes, that's right. romwidth=16. The NP++ example is a file made by hex2000 with romwidth=16. If I upload the same segment with UniFlash and export, I get exactly the same file. Therefore I infer that UniFlash must use romwidth=16 internally, at least by default.

    romwidth isn't really a concept in the program loader/exporter of UniFlash. For program load, the loader just parses the address and data information from the hex file, and loads it to the device. Similarly for export, the exporter reads the address and memory from the device and writes it to file.

    In that sense, because C2000 devices are 16-bit addressable, the exported file from UniFlash would match what you might get from the hex utility when using romwidth=16 to generate/export data.

    Kier said:
    I would have thought so too but I can't see how. Certainly I can't see how UniFlash can infer a different romwidth just from the contents of the HEX file alone and I can't see a romwidth GUI setting. So this is why I assert that UniFlash expects romwidth=16 and cannot correctly flash a hex file into a C2000 with a different romwidth hex file.

    I think what you are inferring is mostly true. UniFlash will be able to load a hex file that is exported with romwidth=8, but the address information in the hex file would not match with the original device memory. For your example, the memory addresses for each record would increment by 0x20 in the romwidth=8 case, and therefore when the program loader parses that file, it will write to those addresses only, leaving every other 0x10 block unwritten.

    Thanks.

  • 0 in reply to Ricky Lau
    Mastermind 7510 points

    Thanks for the confirmation.

    I have a specific use case where a 3rd party tool outputs a regular Intel hex file which I want to convert for use with UniFlash. I just wanted to double check UniFlash's operation and expectations.