Getting raw binary file to burn to DSP internal flash memory

Discussion in 'OT Technology' started by CodeX, Sep 28, 2008.

  1. CodeX

    CodeX Guest

    Ok so I have run into a bit of a road block with the project I am working on at work. We have an established handheld product that we have already made initial shipments of and now my boss wants me to figure out how to add the capability for users to upgrade their own firmware.

    So, after reading many technical manuals I got the basic idea. What I am planning is for the user, in normal instrument operation mode, to browse to the firmware upgrade file on a USB flash stick (this capability already exists) and to select it. After a prompt to make sure they want to reflash I will save the necessary information onto external dataflash (such as the file name of the firmware upgrade) and also set a flag somewhere in external non-volatile memory. I will then restart the instrument. When the instrument starts it will always look for this flag, and will only find it after the user has initiated a firmware update.

    Now, all of the code that is going to be responsible for burning the new firmware as well as the code that handles retreiving the data from the dataflash chip needs to be loaded into and run from memory (obviously you can't run from flash if you are going to be erasing and rewriting the entire flash array). So, I found a full API called FlashAPI for this specific DSP that contains pre-built functions to erase, program, and verify the flash memory. I got this into the program and am able to copy it in its entirety to memory, and have also tested it by erasing a sector, which obviously hosed the instrument lol. My only problem is getting the ROM image of the firmware...

    We use an IDE called Code Composer Studio that builds our project (C code by the way) and then an integrated plugin to flash the chip. The only file I can find is a *.out file in the debug directory, which I found out to be a COFF file. I found a utility to convert this to Motorola S-Record format ASCII hex, and then an additional utility to convert this hex file into binary, which, if I read the manuals right can then be written directly to memory.

    The problem is, when I use the utility to generate the hex file, I lose ALL of the data segments of the program. We have tons of crap defined in data sections of flash memory, including a 320x240x8 image and about 10,000 characters worth of strings. This info NEEDS to be included in the firmware update files that we give our customers, as it is subject to change (the texts especially, they contain complete on-board help documents). I suppose, if I was so inclined I could write a utility myself to convert this data to binary format, but parsing the COFF file to find it seems like a nightmare, and my boss wants this done by the end of the week.

    I was hoping someone here might have experience with something similiar, specifically I am using a Texas Instruments TMS320C2812 DSP, the COFF to Hex utility is called Hex2000.exe... I can provide the memory map of our project as well as my command file that I use to provide settings to the Hex2000 program (instead of command line arguments) and the warnings the utility gives me upon conversion (basically says any section defined in data space is in "unconfigured memory") if necessary...

    Thanks in advance, I know this is a long shot and I have also asked on the TI forums and on DSPRelated.com forums :hs:
     
  2. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    Can't you just erase the program blocks? That's what BIOS flashing does, it doesn't touch the data blocks.
     
  3. CodeX

    CodeX Guest

    Yeah I can, but unless I am totally misunderstanding this we have large blocks of data in the middle of the code that potentially needs to be updated as well...

    Basically, we have 128kb contiguous array of flash memory (parts of it are reserved and we worked around this), segmented into 10 sectors ('A' - 'J') , we have code space and data space allocated seemingly randomly (I did not do this) such that we have, for example, a defined block of data space in between 2 blocks of code space, and also data and code space allocated on the same sector.

    What I was HOPING to get was a file exactly 128kb large, with any unused bytes filled with 0xFF (erased). The program function of the flash API takes a beginning address, a length, and a pointer to the first byte of data to be programmed. So ideally I would give it the absolute beginning address of flash, the length of 128kb, and then the data pointer with the exactly 128kb ROM image file to program the flash memory with.

    If I cannot get the data portions into that file, then I have to erase/program the sectors independently, and like I said some sectors contain both code and data, meaning data sections would be erased (you can only erase full sectors at a time).
     
  4. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    Hmm.

    I think it would be easier to wipe the whole thing, flash it, and then have it retrieve the data blocks from a separate file on the next reboot. EDIT: Or is the problem that you don't know what the data is to begin with?

    You might also want to stomp some punk asses for not keeping the data and program blocks contiguous. That's bad design, and you're the one eating shit for it.
     
  5. CodeX

    CodeX Guest

    Unfortunately that punk ass would be my boss... :rofl:

    Yeah, if no one else has any suggestions at the other places I asked this I guess I am left to devising some separate solution to programming the data sections...
     

Share This Page