I've downloaded the evaluation versin of uVision 4 and wondering if it is suitable for a project that we will be starting soon.
The SRS of the project states that the application must be broken into two parts: Bootloader(8K Max) Application(56K Max)
The boot loader must calculate the CRC32 of itself, then the application, and fall into fail safe if the checksum is incorrect.
Can the linker calculate the CRC32 and place the result in the destination executable? Or is there another application that can take the resulting file and calculate the checksum?
Hello Steven, hello Per,
in some project I used the following solution: I defined a header-structure with markers which is at the beginning of the loaded image. so the bootloader ("bootware") can verify this header - in fact is searches for it at the possible start positions of the application ("firmware").
Some tool SW is needed to modify the image after linking, in my case the hex file.
Advantages over a simpler solution: - several rom sections can be checked - checksum calculation only for the used areas saves time - only used areas have to be flashed (happy developer) - additional embedding of version information at a known location
Example (cut out of startup for a STR710):
__startup PROC LDR PC,Reset_Addr ; jump to entry point ENDP ; This is the header which is needed by bootware to detect a valid loaded firmware image DCD 0xAAAAAAAA ; marks header start DCB 0x01 ; set to 1 to indicate Firmware DCB FW_VERSION_MAIN ; Version Main DCB FW_VERSION_SUB ; Version Sub DCB FW_VERSION_REL ; Version Release DCD Vectors ; start of checksummed area DCD 0 ; length of checksummed area in bytes (inserted by CRCHex) DCD 0 ; checksum (inserted by CRCHex) DCD 0x60000000 ; start of checksummed area DCD 0 ; length of checksummed area in bytes (inserted by CRCHex) DCD 0 ; checksum (inserted by CRCHex) DCD 0xAAAAAAAA ; marks header end Vectors PROC LDR PC,Reset_Addr ; 0
Note header itself is not checksummed in the shown example.
Regards, Martin
For download files, I normally have a header at the start, to allow the boot loader to spit and complain instantly if someone tries to send a binary that is intended for a different hardware platform, or to warn about potential incompatible downgrades etc.
For stored binary, I normally have a block at the end, which allows the start to begin with an interrupt table or similar. If the memory architecture of the platform is complicated, I may store an index to extra information at a fixed location somewhere in the early part of the binary - for example directly after the last interrupt vector.
One thing with a CRC stored at the end of a memory block is that I can have the boot loader compute the CRC for the full block and expect it to end up with the value 0. This is a bit simpler than computing the CRC for everything but the CRC and then compare with the stored CRC.
I normally do want all bytes checksummed, even if there are unused parts of the flash. If they suddenly changes contents then either the program has a bug trigging IAP flash overwrites, or there is something wrong with the flash (maybe device running at too high temperatures) and more bits are likely to fail soon.