TM4C1294NCPDT: CRC32 For Ethernet Bootloader

Hey Charles,

Thank you for your reply. Both posts you mentioned mostly answered my question. The only thing i would have to add/ask is regarding the vector table offset.

As Peter mentioned, we can change the offset of the vector table by changing the value of its definition within the relevant source file. Although, without using the -d option on the binpack tool, the vector table stays at the same address (as if not using binpack at all to process the .bin file). The only thing i can see when using the -d option is the header that it adds to the binary file with the pattern 0x01 0x00 + app_start_address/1024 and shifts everything else to the right.

1) So, my first question regarding this (extra) header is: Why do we even need this header if the markers (0xFF01FF02 & 0xFF01FF02) are placed at the end of the vector table? What this extra header at the top of the bin file means? The documentations says 'Adds a simple download header to the output image'. What that means and why do we need this download header? From which part of the bootloader and/or application this header is used? (Hasn't been tested yet, will test it on Monday)

2) My second question is regarding the vector table offset. In Amit's post, it is mentioned that after the markers (0xFF01FF02 & 0xFF01FF02) we should add the 4 reserved words of 0xFFFFFFFF. That is also mentioned within the binpack tool documentation. Is there a specific reason for adding the 0xFFFFFFFF four times after the markers? From the produced binary file i can see that they will just add these additional FF's at the end of the vector table. (Hasn't been tested yet, will test it on Monday)

Based on this link, it says that "... this header (0x01 0x00 + app_start_address/1024) is used by some download tools...". Thus, i suppose that since my download tool is not making use of this header, there is no need to use it (i think that might answers question 1 above, but wanted to also ask that just to be 100% sure).

Just for your info, i'm not using the LM flash programmer. I have written my own tool in Python to update the board, which basically is reading the bin file and updates the board through ethernet and using UDP socket for the TFTP (i got rid of the BOOTP since it is not needed for the nature of my project).

Once more, thank you in advance for your help! Will come back with some results on Monday 24th.

Hi,

Mpekatsa said:

1) So, my first question regarding this (extra) header is: Why do we even need this header if the markers (0xFF01FF02 & 0xFF01FF02) are placed at the end of the vector table? What this extra header at the top of the bin file means? The documentations says 'Adds a simple download header to the output image'. What that means and why do we need this download header? From which part of the bootloader and/or application this header is used? (Hasn't been tested yet, will test it on Monday)

I don't really know. My best guess is that some tools (e.g. dfuwrap) insert this header on top of the markers that is already inserted in the end of the vector table. The binpack tool has the below description.

To add this header, invoke binpack with the “-d” command line
option. The header structure used is exactly the same as added by the dfuwrap utility. The
first half word contains the fixed value 0x0001, the second half word contains the image flash
address expressed as a number of kilobytes (address / 1024), and the remaining 4 bytes are
written with the size of the binary image excluding the header.

Mpekatsa said:

2) My second question is regarding the vector table offset. In Amit's post, it is mentioned that after the markers (0xFF01FF02 & 0xFF01FF02) we should add the 4 reserved words of 0xFFFFFFFF. That is also mentioned within the binpack tool documentation. Is there a specific reason for adding the 0xFFFFFFFF four times after the markers? From the produced binary file i can see that they will just add these additional FF's at the end of the vector table. (Hasn't been tested yet, will test it on Monday)

My best guess these reserved spaces might be for future enhancements.

Hello Charles,

Thank for your reply.

I'm coming back with the results of my tests.

1) I have included the header markers + image len + crc + FF's in my vector table and i have compiled the project successfully. Just for the people that use Keil and might need to add these headers at the bottom of the vector table (within the startup_rvmdk.s file), they just need to include the following code just after the last interrupt

DCD     HEADER_FIRST_MARKER         ; Header Marker 1 used by binpack tool
DCD     HEANDER_SECOND_MARKER       ; Header Marker 2 used by binpack tool
DCD     HEADER_IMAGE_LEN            ; Header Image Length used by binpack tool
DCD     HEADER_IMAGE_CRC            ; Header image CRC used by binpack tool
DCD     HEADER_RESERVED_1           ; Reserved word used by binpack tool
DCD     HEADER_RESERVED_2           ; Reserved word used by binpack tool
DCD     HEADER_RESERVED_3           ; Reserved word used by binpack tool
DCD     HEADER_RESERVED_4           ; Reserved word used by binpack tool

At least that how i included these headers in my project.

2) Then, after compiling and getting the produced bin file from Keil, i used the binpack tool to process this file and embedded the CRC. I have checked that bin file using a hex editor and indeed i found at the end of the vector table the headers mentioned above, with the correct values for length and CRC.

3) After processing of with binpack tool, i have taken the newly generated bin file and loaded into the TM4C1294NCPDT using LM Flash Programmer. 

4) Then, i have opened the Python script i'm using for updating the board through ethernet and i have updated the board with a new firmware image, to make sure that the new image will pass the CRC. Indeed, the CRC was absolutely fine and the board updated successfully without any issues.

Another test i have tried was to load a corrupted binary file, where half of it was filled manually by 0x00's and the rest left untouched. After loading the corrupted file on the board, the bootloader couldn't detect the CRC and the rest of the headers, so it started sending TFTP requests in order to update the board with a valid image. 

Just for your info, i haven't used LM Flash Programmer at all. The ethernet updates have been performed using my own script. The LM Flash Programmer is only used when i need to load the firmware through JTAG.

4) In order to automate the process of generating the binary file with the embedded CRC a little bit, i have added the processing as post-build command. First, i created a .cmd file with the following command

..\ThirdParty\binpack\binpack.exe -i .\rvmdk\initial.bin -o .\rvmdk\processed_CRC32.bin -x

and then, within the post-build commands i have added the following command

..\ThirdParty\binpack\binpack.cmd

to generate the final binary file (the one that includes the CRC) immediately after compiling the project (successfully) within Keil.

So, i can say confidently that there is no need to use the -d command when processing with the binpack tool. Actually, it depends on your needs. For my project there is no need to add the extra download header at the top of the file. I only need to add the calculated CRC. In addition, there is no need to change the offset of the vector table if the -d is not added.

Finally, the CRC is checked within the bootloader, but i have slightly changed at which place the CRC is checked. I have modified some parts of the ethernet bootloader to fit my needs for this specific project. 

That's all regarding the binpack and CRC for any firmware. I would be happy to answer further question that might help the community to sort out any issues :)

Charles, thank you once more for your replies. Amit and Peter, your posts also helped a lot to understand what's going on. 

Hi Mpekatsa,

 I'm very glad that you are able to test it out and confirm its working. I will reference your post to people who might ask the same question in the future.