CRC for MSP430 Flash downloading

Hi

Do you really need to use CCE?

IAR can automatically perform this task for you.

AES

How about using the Flash marginal read modes to chech CRC?

I think this can predict Flash failures before it actually fails.

Hi,

Thanks for your reply.

We are using CCE. Can you plz tell how it can be done  using CCE

with thanks,

Aju

Have you come up with a solution ? I have actually the same question than yours...

Hi folks, did anyone come up with a solution?  I have exactly the same problem.  Further, the memory map of the MSP430 is a little strange, so what is the expected starting and ending address for calculating the CRC?  Where should the calculated CRC be stored in the Flash memory space?

Please help - seems a number of us have this problem!

Scott

I normally let the more knowledgeable (and frequent) posters deal with the questions, but this thread has been sitting here unanswered for a while, so I guess I'll give it a shot.

Scott Whitney80914 said:

Further, the memory map of the MSP430 is a little strange, so what is the expected starting and ending address for calculating the CRC?  Where should the calculated CRC be stored in the Flash memory space?

You can go any direction you like. The BYTE order doesn't matter for CRC as long as the order is consistent for both the CRC creation and the check. The direction you choose (increasing or decreasing memory locations) has to do with what sort of data you are trying to check for error. If I am doing a code CRC (which is what it sounds like all of you want to do) I generally compute from the interrupt vectors (highest address) down to the "beginning" of code (lowest address). The reason I do this is because the interrupt vectors are always in the same place, which makes for a good CRC starting position. The CRC ending position may drift as my build increases or decreases.

I normally store the CRC right at the beginning of the code image, just so I can run from start (interrupt vectors), down to the end (beginning of flash image), all in one swoop, without changing the pointer used in the calculation to point somewhere else. There is really no restriction on where you put the CRC. You could put it anywhere as long as you know where it is.

If you are doing a CRC on data however, which may change a lot during program execution, then I would recommend putting the CRC in its own flash sector with the data. Info flash works good for this case.

Communication channels should use a CRC polynomial which does the computation in the same BIT ORDER as the channel. For example, SPI should use MSBit first, and UART should use LSBit first. Bit order for flash or data storage (data/code not being transmitted over a wire) shouldn't really matter as long as you are consistent. Someone may have more info about how flash degrades over time or due to radiation, etc, which may prove me wrong though.

Look for Cyclic Redundancy Check on Wikipedia if any of this discussion seems weird. Wikipedia makes things so easy. Much easier than surfing IEEE articles, which is how I learned about CRC.

AES said:

IAR can automatically perform this task for you.

True. Unfortunately, as of the last time I tried it (compiler version 4.20 I believe), it would only do the computation with increasing addresses. It may be fixed, but I haven't seen it mentioned in their release notes, so I doubt it.

aju said:

Our present plan is

1.       Convert the .out file generated by CCE  to .bin using a file conversion tool.

2.       Calculate the CRC of the binary from the binary file

3.       Append the CRC to the existing binary (edit the binary file and the add the calculated CRC to write to required flash location)

4.       Convert the .bin again to .out (by file conversion tool) then load the program using CCE tool and JTAG

5.       A routine to calculate CRC and compare with the stored value is written in the firmware.

Sounds complicated. Just calculate the CRC on the image at run time, update the value, and re-flash it. Make sure that you include all code that you want to check (including the CRC checking routine itself)!

Also, PLEASE don't write "pls" or "plz". Spell out the whole word if you could. :)

Folks,

I have something working, and wanted to share it with you.  For CCSv4, you can generate a "TI Text" output file by selecting Build Settings/Build Steps, and then selecting Create flash image: TI-TXT from the drop-down list.  This will generate a {project}.txt file in either the Debug or Release directory.  It will contain just the code that you generated, with holes and gaps that are not filled with anything specific.

There is a tool called SRecord that is available through SourceForge at http://srecord.sourceforge.net/ (many thanks to author Peter Miller!), and it is designed for manipulating various types of output file formats.  It also has filtering and filling capability.  In my case, I'm working with an MSP430F2618, which has Flash between 0x3100 and 0xFFFF, and then Flash2 between 0x10000 and 0x1FFFF.  I wanted to add a CRC-CCITT to the end of the program space, and was eventually able to do so with the following SRecord command file, which I named convert.cmd:

outputFile.txt -titxt
-fill 0x00 0x03100 0x1FFFE
-l-e-crc16 0x1FFFE -BROKEN -Most_To_Least -Augment
-output finalOutputFile.txt -titxt

From the same directory that your TI Text file is in (e.g., Debug), open a command prompt and run the following:

srec_cat @convert.cmd

This will fill any holes with 0x00 over the entire Flash/Flash2 space, then calculate a 16-bit CRC and store it in the last two locations in Flash2, 0x1FFFE-0x1FFFF.  It calculates a CRC-CCITT, which I was able to confirm by running some data through an online calculator, but it took some experimentation to find the right combination of CRC algorithm, most-to-least or least-to-most, and augment or non-augment.  These are described in the SRecord reference manual.

I then have a lookup-table based CRC-CCITT algorithm, which I call during startup to calculate the CRC-CCITT over the range of 0x3100 to 0x1FFFD (everything except the CRC I built with SRecord).  I compare the output of that against the 16-bit value I read from 0x1FFFE-0x1FFFF, and voila - I have matching CRCs!

Unfortunately, you need to somehow program this entire finalOutputFile.txt into your part.  Maybe I'm just stupid, but I could not find any way from within CCSv4 to load a TI-text format file and then program it to the target!!!  Huh??

I found a free download tool from Elprotronics that talks to the MSP430 USB-Debug-Interface.  Just install and run this program, select your device type, browse to where your CRC'd TI-text file is (finalOutputFile.txt in my example), and click Auto Program.  This will erase the flash and program the entire filled and CRC'd image into your device.

Of course, you'd still like to be able to debug it... to do that, open CCSv4, and instead of simply starting a normal debug session where you download the .out file, select Debug..., then your project name, then Debugger, and click the radio button that says "Load symbols only".  Your code was already programmed into the part, so all you need are the symbols for debugging.

Ta-da!  Now you can run your application, set breakpoints, and actually execute a CRC check during startup.  The CRC-CCITT algorithm that I used was found online, but I can post the code here if anyone is interested.  My advice is to calculate a CRC whatever way you deem best (CRC16, CCITT, CRC32, etc.), and then figure out the right combination of switches in SRecord to generate the same result.

As an aside, I understand that the TI-text format is the same file format that is expected by the Bootstrap Loader (BSL), so if you are using the BSL you may be able to update your device directly with this new, filled, CRC'd file using the built-in BSL code.  I have not been able to try this yet.

Any suggestions on the "best" pattern to fill unused space with?  Ideally it would either hang so the watchdog timer could cause a reset, or execute something that will cause a reset (maybe an illegal instruction?)  The debugger shows that my fill pattern of 0x00 generates the instruction BRA @PC over and over.  I am not sure exactly what this does, but it seems to force a return to reset if I set the PC to one of these instructions and then step.  Not sure how to detect the cause of this reset, however.

TI, if you are listening:  Wouldn't it make sense to be able to auto-fill over all remaining memory and calculate a selected type of CRC right from within Code Composer Studio?  It seems like I had to jump through lots of hoops to do something that many of us apparently need, and that the IAR tools apparently do already.  Comments?

Good luck, and let me know if you have any success with this method!

Scott Whitney80914 said:

I then have a lookup-table based CRC-CCITT algorithm, which I call during startup to calculate the CRC-CCITT over the range of 0x3100 to 0x1FFFD (everything except the CRC I built with SRecord).  I compare the output of that against the 16-bit value I read from 0x1FFFE-0x1FFFF, and voila - I have matching CRCs!

For such a large data set it doesn't really make a difference, but for checking small data packets with CRC, this is a noticeable performance increase.

Thanks, Jens-Michael - I had forgotten that from my data communications and discrete math courses.  I will modify my CRC check and give it a try!