• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 1968 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.

CC2640 OAD for off chip Flash Meta Data and hex file processing

Ralph Deffke
Expert 2915 points

Hi there,

while processing the given documentation on the OAD SimplelinkBLEPeripheral sample project I stumbled over some cryptic statements.

The OAD Guide cites:

"Unlike OAD Image for On-chip OAD, OAD Image for Off-chip OAD doesn’t have the metadata embedded. Instead, it has just 2-byte CRC and 14-byte 0xFF’s in the beginning. Anyway, the first 16 bytes can be ignorable."

I would interpret that as the fact that the first block written to the Image Block Characteristics is 2 bytes CRC and 14 bytes of 0xFF's, correct ?

Obviously after writing the Metadata to the Image Notify Characteristics.

About the Metadata structure:

CRC is a CRC16

CRC shadow is the binary complement of the CRC

Version needs to be always higher then the version on chip or 0, correct? so to "reflash" the device with the same image loaded previously Version can be set to 0 ?

Length it says it is 4 times the Length in byte, in view from somebody processing the hex file it is 1/4 of the length of the to bin conversion of the hex file.

Start Address in case of off chip OAD should be always 0, correct?

Thanks for any help

  • 0
    TI__Mastermind 25035 points
    Hi,
    The embedded metadata is talking about the first 16 bytes in the hex file which can be ignored. The off-chip OAD calculates the metadata separately.

    Yes CRC is CRC16
    CRC shadow should be computed same as CRC, CRC shadow is calculated by BIM on OAD Target
    Version should be user configurable
    Length is 1/4 of the hex image
    Start address is set based on the hex image on where the image should reside in on-chip flash

    Best wishes
  • 0 in reply to Zahid Haq
    Expert 2915 points

    Hi Zahid,

    thank you for replying, however, I tried to be very specific in my question and your answer does leave me alone with what I was asking regarding the hex file computation.

    I am asking this because we are developing an Android app performing OAD.

    This App has to compute the hex file created by CCS, this is the point of view here.

    So by guessing what you say is, that the off chip OAD image created by CCS is valid entirely, the first 16 byte are not to ignore.

    Second, the hex file created by CCS does include only data records, not one start address record, and obviously the end of file record.

    by guessing on your answer, the start address of that image is the start address given in the first data record of the hex file.

    Please, may you confirm these statements  ?

    Thanks in advance.

  • 0 in reply to Ralph Deffke
    TI__Mastermind 25035 points

    Hi Ralph,

    If you are making an Android app, I would follow same procedure as our SensorTag Android app:

    https://git.ti.com/sensortag-20-android

     specifically look in the FwUpdateActivity_CC26xx.java for image setup implementation.

     

    Best wishes

  • 0 in reply to Zahid Haq
    Expert 2915 points
    Hi Zahid,

    can you please recognize that the sensorTag app deals with .bin files? you should get deducted 1000 point really

    so is anybody out there knowing the hexfile processing for OFF CHIP OAD based on the SimpleBLEperipheral sample project ?

    The generated hexfile is about 128Kb big, the hex file does use, however, 16bit address field hence address range of 65534

    Question remains, HOW TO PROCESS THE HEXFILE ?

    Thank you
  • 0 in reply to Ralph Deffke
    TI__Guru** 105180 points

    Hello Ralph,

    Ralph Deffke said:
    The generated hexfile is about 128Kb big, the hex file does use, however, 16bit address field hence address range of 65534

    This statement is not entirely correct; the hex files are generated in Intel Hex format and allow addressing up to 32bits. Please see the Wikipedia article on Intel Hex or similar articles on the Intel Hex standard. Pay special attention to the "Extended Linear Address" record type.

    Processing of hex files is not provided by TI, although some examples are provided using external tools (e.g., hex2bin).

    Best wishes

  • 0 in reply to JXS
    Expert 2915 points
    Hi JXS,

    thanks I did oversee the extended linear address record in line 2757.

    However, processing the hexfile was not limited to reading it. I also want to make sure that it is created properly. As you agreed in this thread e2e.ti.com/.../455801 the recommended py script in the OAD project doesn't work, I would like to know about the boundaries set for hextobin.py for the output file and for all input files. The output file is set to 0x1000 to 0x1FFF. does this mean that the adresses need to be shifted to start at 1000h ?

    In another thread I was told that the BIM hexfile need to be included as well, WHAT IS NOT MENTIONED IN THE OAD GUIDE, but seem to be logical. I assume the hexfile range for the BIM is starting at 0x0h, can you advice about this ?

    Related to this, what is the start address in the characteristics for the OAD image ? I thought it is 0x0h.

    I am getting there and I am planning on a guide for external Flash OAD for the community

    Thanks

    Ralph
  • 0 in reply to Ralph Deffke
    TI__Guru** 105180 points
    Hello Ralph,

    Coming back to this.. The hex merge scripts do work, but the newer installs seem to require more work to get them to work in Windows. The older IntelHex release seems to work better (one with the installer), IMO.

    As stated in the other thread, the BIM is required; the STK wiki was updated but we'll make this more clear in a future OAD doc update. Thanks for the feedback. The BIM contains the int vectors (page 0) as well as the CCFG and BIM code itself in page 31 (last page). Thus, the BIM, App & Stack all have unique, non-overlapping flash pages. Therefore, you can merge the respective hex images into one hex image, let's call it a factory superhex, then convert that superhex to bin, starting at 0x0 and filling unused addresses with FFs. The resulting bin image should be exactly 128kB (factory image). For the update image, i.e., what you push over the air, it will be 2 pages less since it won't have the first & last pages.

    Regarding "start address in the characteristics for the OAD image ", I'm not sure what this means. Can you give an example?

    We certainly do appreciate your effort to help the community, and I'm looking forward to seeing the guide!

    Best wishes