CRC module usage Code on dsPIC33EP256MU810

 

vinaykumar105
...the problem is the CRGO flag is not reset after initiating a calculation.

I guess you are refering to CRCCON1bits.CRCGO.
That bit is set and reset by software.  If you are reading in the Family Reference Manual that the module sets CRCGO to zero "after the CRC operation completes," I can tell you for sure that this does not happen with the dsPIC33EP512MU810, so I'm "pretty sure" it is not true for the dsPIC33EP256MU810.
 
If your code depends on the hardware resetting CRCGO, it won't work.  I will also tell you that, in my opinion, the code in the FRM leads a lot to be desired as far as general usability.
 
Bottom line: Describe your application and show us the code that you tried.  Tell us what happened that you didn't expect.  (Tell us how you are testing.)
 
Maybe someone can help you get to the bottom of things.
 
Regards,
 
Dave
 

vinaykumar105
Is looking for interrupts the only way to identify the end of CRC calculation?

You don't actually have to enable the interrupt.  You can simply test the flag in a loop after you have written everything to the CRC FIFO.
 
One concern with relying on the interrupt flag is this:

From the FRM
The CRCIF flag may get set in the middle of a data process sequence if the data is
not provided to the CRC module in time and the CRC FIFO becomes empty.

So, don't just clear the interrupt flag at the beginning of the loop where you write to the FIFO and test the flag after exiting the loop.  (Since, depending on loop overhead and other external conditions---like other interrupts that occur during your CRC routine, the flag may get set somewhere in the loop before the last word.)
Make sure you clear the interrupt flag immediately upon writing the last byte, then wait for the interrupt flag to be set before reading out the calculated CRC.
 
One reliable way that doesn't depend on the interrupt flag:
After you send the last data word/byte to the FIFO, wait for FIFO to be empty, then execute a sufficient number of NOP instructions for the shifting to be complete.  Since the CRC shifter operates twice as fast as the instruction clock, then, for example with a data width of 8 bits, give it four NOPs (8/2= 4)
I doubt that this wastes any more cycles than setting up a loop to test the interrupt flag.  (And if your application can't survive a couple of possibly superfluous NOPs in the CRC routine, you are pretty much doomed anyhow, right?)
 
Regards,

Dave