• AVR Freaks

CRC module usage Code on dsPIC33EP256MU810

Author
vinaykumar105
New Member
  • Total Posts : 2
  • Reward points : 0
  • Joined: 2018/06/13 13:33:53
  • Location: 0
  • Status: offline
2018/10/29 00:38:19 (permalink)
0

CRC module usage Code on dsPIC33EP256MU810

Hello Team,
I am having trouble following the code samples in the Section 27. 32-Bit Programmable Cyclic Redundancy Check (CRC).
 
Is there any update C code which show how to use the CRC module.  The gist of the problem is the CRGO flag is not reset after initiating a calculation.
Thanks
-Vinay
#1

3 Replies Related Threads

    davekw7x
    Entropy++
    • Total Posts : 1827
    • Reward points : 0
    • Joined: 2012/01/16 12:01:07
    • Location: Second star on the right, straight on till morning
    • Status: offline
    Re: CRC module usage Code on dsPIC33EP256MU810 2018/10/29 08:01:12 (permalink)
    0
     
    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
     
    post edited by davekw7x - 2018/10/29 08:20:30

    Sometimes I just can't help myself...
    #2
    vinaykumar105
    New Member
    • Total Posts : 2
    • Reward points : 0
    • Joined: 2018/06/13 13:33:53
    • Location: 0
    • Status: offline
    Re: CRC module usage Code on dsPIC33EP256MU810 2018/10/29 09:16:03 (permalink)
    0
    Thanks Dave, I will post a code sample shortly. At least I am not the only person seeing the CRCCON1bits.CRCGO not resetting.
     
    Is looking for interrupts the only way to identify the end of CRC calculation?
     
    Thanks
    Vinay
    #3
    davekw7x
    Entropy++
    • Total Posts : 1827
    • Reward points : 0
    • Joined: 2012/01/16 12:01:07
    • Location: Second star on the right, straight on till morning
    • Status: offline
    Re: CRC module usage Code on dsPIC33EP256MU810 2018/10/29 09:32:17 (permalink)
    0
    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
     
    post edited by davekw7x - 2018/10/29 11:18:11

    Sometimes I just can't help myself...
    #4
    Jump to:
    © 2019 APG vNext Commercial Version 4.5