cancel
Showing results for 
Search instead for 
Did you mean: 

CRC in .hex file for STM32f103

emalund
Associate III
Posted on October 20, 2011 at 19:54

I have set CRC in IAR builds, can;t find out how to do it in Keil builds

Erik
9 REPLIES 9
Posted on October 21, 2011 at 16:44

I have set CRC in IAR builds, can;t find out how to do it in Keil builds

Not sure I've encountered a method as simple as IAR's, but Keil offers the ability to run external applications pre/post compile/link that can be used to automate such things.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Fleck
Associate II
Posted on October 24, 2011 at 09:45

We use the feature ''run external program'' in Keil: Project Properties, Tab ''User''.

The checksum is calculated by the srecord tools (http://srecord.sf.net) and added to both hex file and axf file. The axf file is a little tricky, you need to find the correct offset in the axf file to put the checksum. Since our checksum is at address 0x8000000 (replacing the reset stack pointer) this was fairly simple.

An example batch file for using srecord tools to put the checksum in an intel hex file at address 0x8000000 is:

rem set some defaults:

rem srecord tools are in ''tools''  subdirectory of current Keil project

set srec_''cat=tools\srec_cat.exe''

rem objectdir-Path is where the hex-file is stored (relative to project dir)

set objdir=''obj''

rem Filename of Hex File

set Hex_File=''h200ng.hex''

rem Start adress in FLASH

set /a start=0x08000000

rem Offset in FLASH (if you want CRC not at the beginning, but elsewhere

set /a _CRC_Chksum_Address_Offset  = start

set /a _CRC16_Chksum_Address_End   = _CRC_Chksum_Address_Offset + 0x2

set /a _CRC_Chksum_Address_End       = _CRC_Chksum_Address_Offset + 0x4

::::::::::::::::::::::::::::::::::::::::::::::::

rem calculate CRC of Intel Hex File and save in file

::::::::::::::::::::::::::::::::::::::::::::::::

%srec_cat% %objdir%/%Hex_File% -Intel -Exclude %_CRC_Chksum_Address_Offset% %_CRC_Chksum_Address_End% -Little_Endian_CRC16 %_CRC_Chksum_Address_Offset% -broken -Fill 0x00 %_CRC16_Chksum_Address_End% %_CRC_Chksum_Address_End% -o %objdir%/%Hex_File% -Intel -Line_Length 43

    rem ''Exclude'': remove area where CRC is stored from hex file

    rem -Little_Endian_CRC16: Calculate and store checksum

    rem -Fill: CRC-16 is only 2 Bytes, thus fill the rest with zero

===================

Admittedly this looks a bit convoluted at first, but the srecord tools are a very powerful set of tools to convert and modify hex files as well as binary files

Definitely worth learning. They replaced a plethora of home-grown tools here.

jens

emalund
Associate III
Posted on October 24, 2011 at 15:07

Nice, but

the STM32 generates 32-buit CRC, why not use it

Posted on October 24, 2011 at 15:48

Nice, but the STM32 generates 32-buit CRC, why not use it.

 

Probably because it's not a byte orientated solution.

I have tools that could do this if there is general interest that could output a hex or binary file from ELF/AXF.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Fleck
Associate II
Posted on October 24, 2011 at 15:48

the question was how to put the CRC in the Hex-File.

This could be used e.g. to check the contents of the Flash after every Reset. Of course it makes sense to put a CRC in the hex-file which uses the same CRC-algortihm ST built into the STM32. We decided to use a CRC-16 for ''historical reasons'', though. The above is just an example, ready for further improvement 😉

jens

Posted on October 24, 2011 at 16:07

I think Erik is coming from the tangent that IAR's solution is better integrated, and very flexible.

Problem is everyone tends to have there own solution too this, or a cross platform method, and this is compounded by ST's choice of a backassward CRC implementation given the bit/byte endian model of the M3.

Doing it in Hex files is particularly problematic as they can be sparse, and do you put the CRC at the end of the object data, or at the end of the ROM. Which means you need to consider the fill pattern, and ROM size.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
emalund
Associate III
Posted on October 24, 2011 at 16:19

I think Erik is coming from the tangent that IAR's solution is better integrated, and very flexible.

 

I do not know about flexible, but after at my previous contract implementing CRC with IAR, I was surprised that Keil did not have it.

Yes, I have implemented ''after the link'' functions in builds before

ST's choice of a backassward CRC implementation given the bit/byte endian model of the M3.

 

just curious, what is ''backassward ''

Doing it in Hex files is particularly problematic as they can be sparse, and do you put the CRC at the end of the object data, or at the end of the ROM. Which means you need to consider the fill pattern, and ROM size.

 

anything but @ end of ROM can be problematic. I do not remember what the 'experience' was, but I remember it.

Erik
Posted on October 24, 2011 at 16:48

just curious, what is ''backassward''

http://en.wiktionary.org/wiki/backasswards#English

It's one of a number of spellings to describe a design that was implemented completely the wrong way around. ie goes backward when you want to go forward.

Fred installed the rear-differential backassward, and now the car will run backward in forward gears.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
emalund
Associate III
Posted on October 24, 2011 at 18:51

sorry, should l;earn to be more concise

just curious, what is ''backassward '' about the ST CRC implementation?