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.

Question about HPI bootloading of C5510

To start off, I've read over the application note: spra763 "Using the 5510 Bootloader", and I feel like I have a good understanding of the process.  I am also very familiar with the use of the C5510 HPI as I have incorporated it into several working applications without problem.  However, now I'm attempting to perform HPI bootloading from a master processor, and I want to make sure I'm doing it properly.  I believe I have the BOOTM pins properly set, but we'll see.

After compiling my project using CCS, I use the HEX55 utility to create a binary file, as in the application note.  I'm left with *.bin and *.mxp files.  

My first question is: does this binary contain all libraries linked in as well as the application?  I believe it does, but I'd like to make sure.

My next question is: do I load the contents of the binary file directly to the C5510, starting at word address 0x8000, as if it's simply data?  This would, of course, be followed by setting the Reset bit in HPIC to allow the processor to begin executing code from the specified program start location.  

My only confusion is the purpose of the *.mxp file.  I've reviewed it, and it specifies locations/sizes of code sections, and the locations make sense.  Should I take these into account in some way when loading the binary?  If so, how would I go about doing that?  I believe it's not necessary to worry about the *.mxp file, but again I'd like to make sure.  I suppose the easiest way to answer these questions on my own would be to try it out and then ask questions if I see problems.  However, I'm not quite at the point where I am able to load the C5510 files to my master processor.  I'm simply looking ahead to make sure my understanding is correct, and I thought these might be fairly straightforward questions those with prior experience might be able to easily answer.

Thanks in advance for your response(s)!

  • I will try to find out a right person who is familiar with C5510 HPI boot-up. 

    Regards,

    Peter Chung

     

  • I think the answer is yes. HPI boot loading you don’t need to create or generate the bootable as with other boot modes.  The host can load code  out file and data directly into the C5510 DRAM/SRAM or External CE0 memory The BL document spra763 that he mentioned should explain that very well and give also examples.

     

    Regards,

    Peter Chung


  • Derek-

    You have to parse hex55 output and extract both address and data.  Suggest to use a format that produces ASCII text output; you should see contiguous address regions that correspond to .map file sections (.text, .const, etc).

    -Jeff

     

  • Thank you for your responses.  Jeff, when I look at the ASCII text output, I see no addresses specified.  I'm still unclear as to how to parse the hex55 output for address and data.  Below I've pasted some consecutive lines from the ASCII file, and these lines came from about 3/4 of the way down the first page (all the previous lines were all 0's).  It appears that there are 192 bytes / line.

     

    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

    00 00 1C E8 00 02 00 00 46 B3 20 20 20 20 20 20 F0 31 00 00 00 18 A4 A9 

    31 00 18 A3 A4 31 00 18 A2 F7 31 FF FF 00 18 A4 62 74 26 49 62 59 46 B2 

    48 04 E6 31 00 00 18 A4 06 00 8B A4 31 00 C3 00 7D C0 01 44 7F C0 01 44 

    6E 04 02 F4 B5 06 98 46 B3 20 20 20 20 20 20 A9 01 E6 03 00 04 09 59 F7 

    31 00 01 00 18 A4 46 B2 A4 31 00 C3 00 7D C0 20 44 7F C0 20 44 14 01 84

     

    Thanks again for your help!

  • I call the hex55 utility in the following way (as specified on p. 8 of SPRA763C - Using the TMS320VC5510 Bootloader):

     

    hex55 -boot -v5510:2 -memwidth 16 -romwidth 16 -map hpi16.mxp -e _main -a -o hpi16.asc my_file.out

  • Hi,

     

    What is the version of hex55?

    You can check by typing "hex55" and enter in the dos window.

    Regards,

    Hyun

  • My hex55 version information:

    TMS320C55x Hex Converter v4.3.8

  • Hi,

     

    I attached an example to generate .bin file from .out.

    Please notice that the entry point of main address should be the first address of .bin file.

     

    BOOT LOADER PARAMETERS

       Table Address:  0x00000000, PAGE 0

       Entry Point:  0x00020d42  (_main)   <--

     

    Bin file:

    00 02 0D 42 00 00 00 00 00 00 00 A0 00 00 19 C8 00 53 00 59 00 53 00 20 

     

    hex tool command:

    hex55.exe -boot -v5510:2 -memwidth 16 -romwidth 16 -map .\tone.map -e _main -a -o tone.bin tone.out

    regards,

    Hyun

    boot_example.zip
  • Thank you, Hyun.  Your response has clarified quite a few things for me.  However, now I have a few questions regarding the format of the output file.  If you examine the tone.bin ASCII file which you have provided, I see the following as the first line:

    00 02 0D 42 00 00 00 00 00 00 00 A0 00 00 19 C8 ...

    Examining just that portion of the line, I see the _main entry point address (00 02 0D 42) followed by 4 additional bytes which seem to not correspond with anything. Continuing, I see (in bold) the .const section size (00 00 00 A0) and address (00 00 19 C8), which makes perfect sense.  If you traverse the file by the specified 0xA0 bytes, you come to 

    00 00 00 10 00 00 1B 1C

    which can be seen to be the size and address of the .args section.  Continuing on through the rest of the file, I can find the corresponding size and address of each of the rest of the sections in this manner (size followed by addr followed by data).  At the very end of the file are again 4 additional bytes (all 0's) which seem to not correspond to anything.

     

    If you add up all the numbers in the .bin file, you come up with 12294 bytes which are listed.  Sizes of all the sections + 12 sections * 8 bytes/section (size+addr) = 12278 bytes.  4 bytes for the addr of _main and 4 additional bytes (following the addr of _main) + 4 bytes at the end of the file = 12290 bytes.  That leaves 4 bytes listed in the .bin file which I can't seem to find.

     

    What do the 4 additional bytes following the address of _main correspond to?

    What do the 4 additional bytes at the end of the file correspond to?

    Where do you suppose the 4 bytes which seem to be unaccounted for reside, and to what do they correspond?
    Again, I greatly appreciate your time and help.  Thanks!

  • Hi,

     

    I think that you have not read boot table structure in "Using the TMS320VC5510 Bootloader" (SPRA763C) document section 2.4.2. It explains everything.

    http://focus.ti.com/lit/an/spra763c/spra763c.pdf

    Regards,

    Hyun

  • Thanks again.  I suppose I was confused by the multitude of places in that document where it specifies that booting using EHPI does not use a boot table.  That section did answer for me the purpose of the 4 bytes following the entry point as well as the 4 bytes at the end of the boot table.  However, there are still 4 bytes of data listed within the ASCII file which I wonder about.  I can attribute 3 of them to padding, as explained below, but not necessarily the 4th.

    Section 2.4.4 of the document specifies the need for pad bytes given specific conditions, such as a program section beginning on an odd byte address or ending on an even byte address.  Examining the start and end locations of the sections in the tone.map file, I see that 3 of them will have padding added (.text will have a pad byte at the end, and .sysinit/.rtdx_text will each have a pad byte at the beginning of the section).  This answers for me the locations of 3 of the 4 additional bytes I see in the .map file.  Examining the ASCII file, I see that at the beginning of the .sysinit and .rtdx_text sections there are entries: 0x20.  According to Section 2.4.4 of the bootloader document, these should be pad bytes.  If I assume that these are padding bytes, and I examine the end of the .text section, I again see an entry for 0x20, as explained in the document.  At the end of the .text section, however, there are actually 2 entries for 0x20.  According to the bootloader documentation, there are no instances where the hex55 utility will insert 2 pad bytes next to each other.

    Should I make the assumption that the .text section has 2 pad bytes at the end?  Or is there an explanation of where the last unaccounted for byte comes from?  Also, it seems to me that I need to strip out the pad bytes before writing the program sections to the DSP - is this true?  

    The reason I am interested in the one extra byte in your example is simply because, according to the rules outlined in the the bootloader document, I have 96 unaccounted for bytes in my own boot table.

    Thanks again for your help.

  • Hi,

    Indeed it's true that hex tool is generating extra byte when a section is in odd size as you observed. This is for hex tool to protect the section starting address in even address for

    the bootloader.

     

    Regards,

    Hyun

  • Sure, but does that mean that the host which is bootloading the 5510 will have to strip out the extra bytes contained in the hex tool output?

  • Hi,

    No, the bootloader takes care of it. You don't need to do any modification on it. Please use as is.

    Host should act like a simple rom which provide boot code as is.

    Regards,

    Hyun

  • According to my understanding of SPRA763 (Section 2.3.3 EHPI Boot Mode), in HPI boot mode, the bootloader's only function is to poll the RESET bit in HPIC to determine when the host has finished loading code/data sections to the DSP.  The setting of the RESET bit causes the CPU to then begin execution at byte address 0x10000.

    The fact that the host loads the code and data sections directly into DSP internal memory leads me to believe that it is the host's responsibility to remove the pad bytes from the boot table generated by hex55.  Further indication of this is provided in Section 4.2 Host Port Interface Boot Mode: "Verify that byte address 0x10000 contains the start of executable code (not a boot table)."

    Which leads me to the following question: how does the CPU know how to branch to the _main entry point?  Is the location of the entry point loaded to byte address 0x10000?

  • Another question: regarding byte-addressing vs. word-addressing.  According to SPRU588 TMS320VC5510 DSP HPI Reference Guide, p. 11: "Addresses driven by a host on the external address lines of the HPI are treated as word addresses, not byte addresses."  This means that I cannot load data starting at odd byte addresses over the 16-bit HPI.

    Since the sections listed in the map file produced by the hex55 utility are byte addresses, how can I handle sections whose destination is an odd byte address?

  • Hi,

     

    I'm feeling that you fully understood HPI bootloading. When you compile your application, you need to set your entry point as 0x10000.

    I attached another example to set 0x10000 as an entry point. In cmd file SARAM0 (origin = 0x10000) is first assigned to .text.

     

    Regards,

    Hyun

    dma1.zip