With USB goes medical I have a serial-to-USB (CDC) support for my TWR-S08MM128 board. What makes these devices targeted for medical applications interesting for other applications are features like bootloader support and a CRC (Cyclic Redundancy Check) engine. But how can I generate the required CRC numbers with MCU10?
The CRC features is described in chapter 11 of the S08MM128 reference manual. It exists for other devices like the JE family or for the MCF51MM256, see chapter 13 of the Reference Manual).
That CRC is checked in boot-loader mode, so I need to calculate it for images loaded by the bootloader. Calculating that checksum by hand is not something I want to do, as it changes all the time with my recompilation of the binary. So I need a tool which can do that for me. And there seems to be some light at the end of the tunnel.
CRC Generation in Classic CodeWarrior
In classic CodeWarrior, if I create a project for the MCF51MM256, I get a CRC Post-Linker set up:
CRC Post-Linker in Classic CodeWarrior
Note: Somehow the CRC PostLinker is only supported for ColdFire V1 devices in classic CodeWarrior, but not for S08 ones?
In the corresponding CRC PostLinker panel I can specify the configuration file (*.crc) and some options:
CRC Postlinker Settings in classic CodeWarrior
Looking behind the scenes, it is obvious that following tool is used:
<installation path of MCU6.3>\bin\plugins\Support\crcgen.exe
Running that executable from the DOS shell gives:
crcgen.exe options
Searching the classic CodeWarrior documentation, I find the following information:
CRC tool Release Notes =============================================================================== version 0.1 - July 14th 2009 The CRC tool computes a CRC-16 on physical address ranges as defined in the configuration file. The tool loads ELF segments and computes a CRC filling unused bytes with a fill value. The CRC values are written as distinct ELF segments. crcgen input [-crc file] [-le] [-o file] [-srec [file [length]]] [-bin [file [length]]] options: -crc file - crc range description file -le - use little endian target addresses -o file - output ELF file -srec file length - Srecord output, optional filename and record length -bin file length - Brecord output, optional filename and record length CRC file syntax: File ::= Hdr Seed Fill Ranges Dest Hdr ::= 'CRC' Seed ::= 'SEED' '=' number Fill ::= 'FILL' '=' number Ranges ::= Range * Ranges ::= 'FROM' number 'TO' number ';' Dest ::= 'DEST' '=' address
Well, that’s not much of documentation, but gives the idea.
Warning: the options suggests that I just could use -srec. But I have found that the generated S19 files are incorrect (with zero size records). What worked for me is something like -srec myFile.S19 32
The syntax of a .crc file is best explained with the example taken from the MCF51MM256:
CRC SEED = 0 FILL = 0xFF FROM 0x00000000 TO 0x000003E4; FROM 0x00000410 TO 0x0000F7FF; FROM 0x00010800 TO 0x0002F7FF; FROM 0x00020800 TO 0x0003FFFF; DEST = 0x408
The destination address is at 0x408 as the CRCH:CRCL (CRC High and Low) 16bit register are at that address (see device memory map).
With this, the CRC calculation is easy: is is performed as a post linker step in the build.
CRC Generation in Eclipse based CodeWarrior for MCU10
Doing the same in CodeWarrior for MCU10 starts with a problem: The crcgen.exe is not installed with MCU10.2?
This is not a big problem with the knowledge from above, and if I still have MCU6.3: I have the crcgen.exe here:
<installation path of MCU6.3>\bin\plugins\Support\crcgen.exe
So I can copy that file to:
<installation path of MCU10.2>\MCU\bin\plugins\Support\crcgen.exe
I create a .crc file in my project and configure the post-linker in MCU10 to use it:
Post-build Steps in MCU10
As post-build I have following command line specified:
"${MCU_TOOLS_HOME}/bin/plugins/support/crcgen.exe" "${BuildLocation}/${BuildArtifactFileName}" -crc "${ProjDirPath}/Project_Settings/Linker_Files/calc_crc.crc" -o "${BuildLocation}/${BuildArtifactFileName}.crc.elf"
This command line uses several Eclipse variables:
- ${MCU_TOOLS_HOME}: points to the MCU folder inside my CodeWarrior MCU10 installation
- $(BuildLocation}: points to the output folder inside my project of my build where my ELF file is located
- ${BuildArtifactFileName}: this variable contains the file name of my ELF file
- ${ProjDirPath}: folder name of my project
Now if I do a build, the post build step will be executed as well to calculate the CRC into my application:
Post Build Step in Console View
Summary
Using the post linker and the crcgen.exe can be easily used in eclipse base CodeWarrior to generate the CRC. Now I just need to make sure that my bootloader is working properly. But this will be another story ….
Happy CRCing 🙂
MCU on Eclipse 
Hi Erich; this appears to work at first glance, but seems to produce the same CRC no matter what I change. I’m guessing that maybe Freescale changed something in the ELF format that wrecks this tool or it has some incompatibilities with 64-bit Windows. Either way, it sadly doesn’t work for me, and I have to say, I’m shocked to find that Freescale has no built-in CRC function in the linker. Truly abysmal…
LikeLike
Hi Renee,
I wanted to look into this yesterday, only that I have found out that my MCF51MM board is broken (not sure why). I’ll see how I can reproduce what you say. As a side note: the S08 linker has a built in CRC checking and CRC generation. But this of course does not help if using a ColdFire. Given the fact that crcgen.exe is so hidden, and there is nearly no documentation for it, I’m wondering if it is used at all? Maybe 99% of the users do not use CRC checking in their applications? Honestly, I used it in very few places too. Maybe because as in our case, things are not that easy to use, both in the silicon and in the tools?
LikeLike
Hi Renee, I managed to fix my broken Tower MCF51MM256 board. I’m using the setup and crc generation file as used in this blog post, and I can say that the CRC code changes for me when I change my code? Maybe verify that you are using the proper mapping of memory in the CRC file?
LikeLike
Sorry for the late reply, been super busy and must have missed the email.
Here’s the CRC file, pretty straight forward. Bootloader is in the low 8KB; I’ve played around with the SEED and FILL values, and they don’t seem to be any different either. The ColdFire+ doesn’t have the same built-in CRC verification mechanism found in the earlier V1’s so the location is simply at the head of my “application” space along with a small entry table located between 2000 and 2010.
CRC
SEED = 0xFFFF
FILL = 0xFF
FROM 0x00002010 TO 0x0000FFFF;
DEST = 0x200C
It spat out my S19 and every time with the exact same CRC. For a sample test, the first build was with everything compiled as 32-bit floats (last S19 address line is 61E0):
S3070000200C3D206F
Rebuilt the project using 64-bit floats, pushing the last-line to 7BA4 and the CRC line is still:
S3070000200C3D206F
I’ve disassembled the ELF, and confirmed that it’s the same, and obviously not being correctly computed. The statistical odds of several random recompile attempts generating the same CRC are astronomical. I also double-checked the pre-CRC S19 file so ensure that there wasn’t already data at the location that might have been confusing the CRC generator.
On the subject of using CRCs in particular, that may be true. I can see with ColdFire V2’s and up why they don’t care since you’re more likely to be using FAT anyway with a “real” OS which will perform any amount of checking for you. The Serial Bootloader (AN2295) only more recently got a CRC added to it, and what it does is have the PC software calculate the CRC and send it separately as a command instead of “wasting” a couple bytes of ROM. This doesn’t protect against deliberate tampering of the firmware image though (not that a CRC16 helps **MUCH**, but it deters any casual attempt), nor does it protect a binary image that was downloaded from the internet with errors.
Freescale hasn’t given much love to bootloaders; the ColdFire+ only has two for download over USB, and both require more than 40KB of flash, and not ONE provides for a surefire way to enter bootloader mode without hardware intervention. AFAIK, only the S08JS has a reset-and-state mechanism built into it (which is awesome), but sadly, I’ve seen nothing like it in any other Freescale chip. The PDHC 4.x code is a bastion of interesting tidbits though; their Processor Expert demo projects use the MCG for USB (which otherwise Freescale says is a no-no), and their MSD demo app takes 1/4 the space that their MSD bootloader app does and appears to work just fine.
Anyway, thank you very much for your help; this blog alone has been more help than just about any other resource!
LikeLike
Hello,
thanks for your extensive response. All what I can say is that this crc_gen.exe works on my end with my MCF51MM256. As noted in my blog, it seems that although that utility should be generic (just read/write ELF files), it does not work for the S08. So I’m not sure what device you are using, so this might be the problem. If you have not submitted a service request to Freescale, then I suggest to do so (but from what you say, you probably already did so).
In any case, if this is helpful, I have uploaded a simple test project (for MCU10.2) and my ColdFire MCF51MM256 (Tower) board which works on my end. If I change the code, change the seed or change the fill parameter, I get different CRC values as expected. So you might try this on your end, and maybe it is a different problem? I’m using Win7 32bit.
Here is the link to the example project: http://www.steinerberg.com/EmbeddedComponents/Examples/CRC/MM256_CRC.zip
I hope this helps.
LikeLike
Hi Eric,
I’ve ran your project and came up with the same issue Rene did. I also see a 3d20 at address location x408, in both the myFile.S19 and the MM256_CRC.elf.
This is making me wonder if our version of crcgen isn’t a problem. Or maybe we’re looking at the wrong place for the CRC. Can you post your version of crcgen.exe?
LikeLike
Hi Again,
I updated CW6.3 to the latest updates (got the idea from the 51MM) and tried it’s crcgen.exe, and it seems to be giving different answers at this point which is progress. Renee has the hardware for the MCF51JU64 so Renee will have to try it all out to verify if it’s working or not. Thanks for the post and help so far.
LikeLike
Hi Bob,
ok, that’s good news. Interesting point that the crcgen.exe seems to be different for previous versions? I think I used it after I had upgraded my installation when my MM256 board arrived. Looking forward to see if things sort out for Renee as well. In any case I have posted the crcgen.exe I use in http://www.steinerberg.com/EmbeddedComponents/Examples/CRC/MM256_CRC.zip.
LikeLike
Hi Bob,
interesting. I have added the crcgen.exe I use to the zip file I posted in the the previous comment with a small readme.txt. Maybe it is because 32bit vs 64bit Windows? I’m using Windows 7 32bit.
LikeLike
Yeah, it was the file — I guess some versions of crcgen don’t work. It’s working great for me now using the file Bob sent me, but not the one I pulled from my own CW6.3 install. I’m not sure why and I’m not sure how we could tell otherwise since Freescale hasn’t put any version information in the file. But great job everyone, this is now in the books as a fully working solution!
LikeLike
Great that it is working for you now too. For everyone else I have put my (working) crcgen.exe into the example project I have posted.
LikeLike
Pingback: S-Record, Intel Hex and Binary Files | MCU on Eclipse
Hi Enrich,
Thanks for the effort. This is a great site. I can’t find this information anywhere including Freescale.
CRCGEN CHECKSUM seems work for me. It generates different CRC every time I modify code, but when I compare the checksum that I calculated, the checksums do not match. However, with the the same calculation (the same code), the checksums match with CHECKSUM generated in H08 project. As you known, H08 provide a tool to calculate the checksum. All I need to do to edit the linker file (prm) such that
CHECKSUM
CHECKSUM_ENTRY METHOD_CRC_CCITT
…..
END
END
I think crcgen.exe use different checksum method. Do you know what that method/formular that is being used? A sample code to calculate the checksum is helped too.
Thanks for your help
Biet
LikeLike
Hi Biet,
thanks :-).
The CRCGEN uses the same checksum calculation method as described in the ColdFire manual. This is the information I have. To my knowledge this is different from what the S08 linker does, but not sure.
LikeLike
Hi Enrich,
Thanks for the quick response. I have it working.
If someone run into the problem like me, you might want to check
SEED value
I set SEED = 0, and it works
LikeLike
ah, good point, thanks for this!
LikeLike
I Eric, you mention here checksum calculation method described in the coldfire manual. Silly question but do you know where, I tried to find it !
Also, I convert the S19 output files in the ./bin folder to binary using srec2bin tool. If crcgen.exe only accepts elf files as input, does this mean I should use the .elf file in the ./bin folder with -bin as an input argument ??
Thanks for your posts and time.
Ps I am using a V2 processor MCF5232CVM150J.
LikeLike
Hi Mark,
yes, the CRCgen only accepts .elf files. The -bin option is an output option, and not for input files.
I don’t know the MCF5232, but as noted in the article, only some ColdFire have implemented it, and are matching the crcgen. I only have found the description as I pointed in the links to the Freescale manuals in the article.
LikeLike
Hi Erich
Good article, i know this post is little old, but i’m doing an check in CRC in my bootloader and i’m using the Kinetis Freescale, Does CRCGEN works with this familiy? Do you know? Thanks
LikeLike
To my knowledge it does not work for Kinetis. Well, it could (technically), but somehow the implementation is only for S08 and ColdFire, but not for ARM.
LikeLike
Thank you!
LikeLike