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.

RTOS/TM4C1294NCPDT: CRC header for TI-RTOS

Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

I want my boot loader to perform a CRC check for a compiled TI-RTOS application. The boot loader needs a header "stored immediately above the vector table and marked by the words 0xFF01FF02 and 0xFF03FF04". A simple solution is given in this post: e2e.ti.com/.../2000471

TI-RTOS projects don't have a startup_ccs.c file AFAIK. How do I edit the vector table?

Amit's instructions seems to contradict the boot loader's instruction. Amit says to put the header after the last table entry. The boot loader asks for the header to be above the table. Should the header be stored before or after the table, or does order not matter?

TivaWare supplies source code to make a program that adds a CRC to binaries, binpack. I didn't realize I need to make this header myself until binpack gave me an error "The input file contains no image info header at the top of the vector table!"

  • Hi Peter,

      I think it depends on how you define as the bottom of the vector table. I think what Amit meant to say is the CRC header to be place after the last entry in the vector table. Obvious if you look at the below table the CRC header cannot be place lower 0x0. In the bootloader it will remap the vector table starting at 0x20000000. So the CRC header's locations will not be less than 0x20000000. 

      As far as the vector table for TI-RTOS application, I will need to ask our TI-RTOS experts. 

  • Peter,

    From the SYS/BIOS API Reference:

    By default, two vector tables are created:
      1. A 15 entry boot vector table is placed at address 0x00000000 in FLASH.
      2. A 50 entry vector table is placed at address 0x20000000 in RAM.
    The FLASH boot vector table contains the reset vector and exception handler vectors used until the RAM based vector table is initialized (as seen in the screenshot above).
    The RAM vector table contains those same first 15 vectors as well as the SysTick vector and the remainder of the user interrupt vectors.
    During system startup, the NVIC Vector Table Offset Register is initialized to point to the RAM vector table after it has been initialized.
    Derrick
  • I have seen this information in other posts and in the HWI module in XGCONF, but I am still unsure what to do.

    The goal is to add a CRC header to this table to make the firmware upgradeable via Ethernet. The tasks is confusing to me because the memory region is used by the lib file myProjectName_pem4f.oem4f . How do I edit this lib file's table as shown in the other E2E post?

    I do not expect the CRC header to be copied into SRAM.

    As a side note, I will be stashing the boot vector table at address 0x4000 instead of 0 because the boot loader is in the address range 0 through 0x4000. These lines from a .map file show the effect:

    SEGMENT ALLOCATION MAP

    run origin load origin length init length attrs members
    ---------- ----------- ---------- ----------- ----- -------
    00004000 00004000 0000a690 0000a690 r-x
    00004000 00004000 0000003c 0000003c r-- .resetVecs

    latter in the file:
    .resetVecs
    * 0 00004000 0000003c
    00004000 0000003c myProjectName_pem4f.oem4f (.resetVecs)

  • Peter,

    You can use the #pragma intrinsic to place your CRC at the desired address. In your case, you want to place a CRC at 0x4040.

    #pragma LOCATION(myCRC, 0x4040);
    static const char myCRC[16] = {0xAB, 0xBC, 0xCD, 0xDE,
                                   0xBC, 0xAB, 0xDE, 0xCD,
                                   0xCD, 0xDE, 0xAB, 0xBC,
                                   0xDE, 0xCD, 0xBC, 0xAB};

    Derrick

  • I added this to a .c file, but the .map file says something else is placed at that address 0x4040:

    section page origin length input sections
    -------- ---- ---------- ---------- ----------------
    .text 0 00004040 000080aa
    00004040 00000430 sysbios.aem4f : BIOS.obj (.text:ti_sysbios_family_arm_m3_Hwi_excDumpRegs__I)



    Does this require edits to the .cmd file?

  • myCRC shows up in the map file when I make some fake code to reference the array:
    int dummy = myCRC[2];

    This hack only works with optimizations turned off. Is there some was to tell the compiler "put this here and I really mean it!"?

    Section 5.10.16 of the ARM Compiler User Guide (SPNU151M) leaves everything to the imagination.

  • Peter Borenstein said:
    myCRC shows up in the map file when I make some fake code to reference the array:

    Try the following to prevent the array from being discarded if not referenced in the code:

    #pragma RETAIN(myCRC)

  • George Mock suggested #pragma RETAIN(myCRC) in another post on the topic. This prevents the linker from removing unused variables.

    This directive is also in SPNU151M, but it is hard to look up something you don't know exists.

    Edit:  also suggests this. I didn't see his post while writing.

  • Peter,

    You may also explicitly specify a symbol using the '--retain' option with the TI linker.

    Derrick
  • Thanks for the help. I just loaded an image to a boot loader that checks the CRC. It works.

  • Thanks to Chester and Derrick!
  • Hi Peter,

    Can you advise me how did you able to generate the CRC check file. I'm trying to generate CRC check bin file with following but no success. Thanks

    "${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/armofd" "${CG_TOOL_ROOT}/bin/armhex" "${CCS_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin"
    "${TIVAWARE_INSTALL}/tools/bin/binpack" -i "${BuildArtifactFileBaseName}.bin" -o "${BuildArtifactFileBaseName}-dfu.bin" -a 0x4000

  • TI provides source code to build an command line tool called binpack with a TivaWare install.

    I used Visual Studio to compile it. Your post build steps seem correct. Make sure the binary file binpack.exe is somewhere in the path or "include files".

    Also, the post build steps in CCS don't run if no changes were made to the .out file. Delete it to force the steps to run.