• Announcements

    • bluehash

      Forum Upgrade   03/11/2017

      Hello Everyone, Thanks for being patient while the forums were being fixed and upgraded. Please see details and report issues in this thread. Thanks!
JRDavisUF

driverlib crc32 problem

8 posts in this topic

win10 - ccsv7 - energia 18 - msp432 launchpad

I'm trying to use the crc32 library from driverlib to do a simple crc-16-ccitt calculation and stumbled across a weird problem.  Just to give a quick background, the way the crc32 library works is the following:

1) initialize

2) add N bytes to be processed

3) request the computation to be done

In order to get the routine to work correctly, I must slow down the code with some additional code in between steps 2 and 3.  This can be operations, Serial.print, or even just a simple 1 us delay.  If I do not do this, the answer I get is equal to the crc checksum of just the N-1 bytes (dumb luck figuring this out).  So it kind of looks like the last byte is not getting added fast enough before the request to perform the crc is being made.  Anyone run across this?  I've not seen it mentioned anywhere.

Example code attached.  This code will repeatedly try and perform a crc until it fails.  When it does fail, it pauses briefly and then reboots.  Currently, it fails instantly for me...but if I add it some timing operations between 2 and 3, for example, it will fail at a seemingly random attempt number.  If you un-comment the 1 us delay, it will run successfully.

Although I've not tested yet, I'm wondering if I will see the same issue appear with the aes256 stuff as well since it looks like its implemented in a similar way.

thx.

jrd

PS  CRC-CCITT (0x1D0F) calculation has been verified a software implementation I haveas well as the value that is calculated here:  https://www.lammertbies.nl/comm/info/crc-calculation.html

 

 

code.ino

Share this post


Link to post
Share on other sites

This sounds like a hardware bug.

Can you reproduce it with a program that uses neither Energia nor driverlib?

Share this post


Link to post
Share on other sites

 I highly doubt that this is an HW issue, though it's possible.... lets start with the code...

Is the Watchdog timer still running? You've not stopped it (though I don't use Energia and don't know if it's stopped by default)..

The code you provided is a bit messy, but is essentially the same as in the driverlib manual, and looks OK, except the WDT is on.

As this seems to be a timing-sensitive issue, I'd start by stopping the WDT.

bluehash likes this

Share this post


Link to post
Share on other sites

I wonder if there's some aggressive compiler optimization going on. The compiler wouldn't know what's happening inside the ROM functions and may put function calls out of order. Maybe worth a try to see if it works with straight calls to the driver lib (i.e. dropping the MAP_ prefix).

PS: The reference manual says, that CRC result is available after 1 clock cycle. Also no mention of CRC issues in the errata.

bluehash likes this

Share this post


Link to post
Share on other sites

Thanks for the ideas.  Energia uses the WDT for other purposes, as such I didn't put it in my code.  However, I just stuck it in and that doesn't help.  I did try getting rid of the MAP_ stuff and that didn't help either.  I also noticed that the example defined the returned crc value as volatile, so I changed that, but it didn't help either.

I missed the 1-clock cycle note.  As such, I changed my 1 microsecond delay to a 1 cycle delay and the code works fine.  I'm guessing that must be the issue. 

bluehash and chicken like this

Share this post


Link to post
Share on other sites

In theory, the function call overhead should have taken care of the one-cycle delay. It appears that in practice, the compiler managed to optimize that away somehow. (I guess your MAP_ functions do not go to ROM but to your own copy of driverlib, and the compiler inlined all of it.)

Share this post


Link to post
Share on other sites

OK, I think I get it now.  I new the rom_map.h header selected the hardware or software version, but I really didn't look into what it was doing.  I was assuming it determined whether or not my rom could support it.  Turns out, one must include the rom header before the rom_map header.  If I do that (or replace MAP_ with ROM_), I don't need any delays to get it to work correctly....So I think Clavier is spot on.

The flip side is that the rom version is significantly slower than the software versions.  So I guess the price one is paying for a reduced code size, is speed?  I guess I get that.

                                                      9/10 bytes              66 bytes

pyCrc                                             13us                         13us

driverlib software Crc                     11us                          27us

rom Crc                                          16us                          74us

chicken likes this

Share this post


Link to post
Share on other sites

Discovered a bug in my code, so for completeness, below are the updating timing numbers:

                                                      9 byte string    9 byte array  64 byte structure

pyCrc                                             13us                    13us              57us**

driverlib software Crc*                    11us                     10us             49us

rom Crc                                          15us                     15us             79us

 

*driverlib software includes a 1us delay to ensure enough time to process results.

** this is the value which was wrong in previous post....pyCyc isn't twice the speed of the driverlib version.  they are actually comparable.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now