Hot!dsPIC33EP256MU806 When is the CRC Module's summation finished?

Author
arigead
Super Member
  • Total Posts : 400
  • Reward points : 0
  • Joined: 2011/02/07 06:58:31
  • Location: 0
  • Status: offline
2018/05/16 06:56:27 (permalink)
0

dsPIC33EP256MU806 When is the CRC Module's summation finished?

I'm working on the CRC for the One Wire protocol, so it's only an 8th order polynomial and 8bit data width. And to make it even easier there's only 7 or 8 bytes to be CRC'd. So reading the document DS70346B it all seems fairly straight forward until you get to the end of the CRC. That document states that -
"When the calculation is complete, the module will clear the GO bit and set the CRC Interrupt Flag (if CRCISEL= 0)."
I'm not using interrupts, as yet, so I'm just spinning on the GO Bit which contrary to the documentation does not get cleared by the module. Has anybody any experience of using this CRC module? It'd be a boon if it worked.
 
Thanks for any help
#1

12 Replies Related Threads

    du00000001
    Just Some Member
    • Total Posts : 1891
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: dsPIC33EP256MU806 When is the CRC Module's summation finished? 2018/05/16 07:48:28 (permalink)
    0
    As there is no recorded problem with the CRC generator in the errata sheet, chance is high that . . . see my footnote!
    BTW: you may check the IF as well. An interrupt is only issued if the corresponding peripheral interrupt enable is set. Many applications poll some IFx while not implementing interrupt service routines.
     
    Are you sure you set up the module correctly and didn't forget to enable it ?

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #2
    arigead
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2011/02/07 06:58:31
    • Location: 0
    • Status: offline
    Re: dsPIC33EP256MU806 When is the CRC Module's summation finished? 2018/05/16 09:37:40 (permalink)
    0
    Thanks for that. So I now waiting for the Interrupt Flag as opposed to the GO bit and yes that is giving me a result. Having said that the result ain't what I'd expect so I've messed up the configuration. Have to re-read this and see what the problem is.
    #3
    Mysil
    Super Member
    • Total Posts : 2760
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: offline
    Re: dsPIC33EP256MU806 When is the CRC Module's summation finished? 2018/05/16 10:10:16 (permalink)
    0
    Hi,
    If you have CRC module working in a mode that implies feeding data to the CRC data input register byte by byte,
    then CRC module cannot know when you are finished, and it make no sense for CRCGO to clear by itself.
     
    Instead check the CRCIF bit as suggested above, it is the procedure used in example code in the FRM.
    About checking CRCIF bit, you may ensure that CRCIF bit is cleared before entering the last data byte, to get a valid flag.
     
    According to the FRM, CRC hardware process 2 bits every instruction cycle, so for 8 bit CRC, 4 Nop(); sould also work.
     
       Mysil
    post edited by Mysil - 2018/05/16 10:15:01
    #4
    arigead
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2011/02/07 06:58:31
    • Location: 0
    • Status: offline
    Re: dsPIC33EP256MU806 When is the CRC Module's summation finished? 2018/05/16 13:01:18 (permalink)
    0
    I was going by the datasheet which states:
    "When the calculation is complete, the module will clear the GO bit and set the CRC Interrupt Flag (if CRCISEL = 0)."
    I'm not sure about your logic that the module doesn't know when to clear the GO bit but it does know when to Set the ISR Flag? Anyhow as I previously posted the ISR Flag does work.
    #5
    arigead
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2011/02/07 06:58:31
    • Location: 0
    • Status: offline
    Re: dsPIC33EP256MU806 When is the CRC Module's summation finished? 2018/05/16 13:28:08 (permalink)
    0
    So I've been pointed to the ISR Flag which does correctly indicate the completion of the CRC calculation. However the CRC calculated by the PIC CRC Engine doesn't appear good. I'm using a One Wire Identifier which I have here:
    CRC  |            Serial Number                           |    Family code
    0x05   0x00 0x08 0x03 0x72 0xc8 0x92      0x10
    The CRC bundled in the OneWire device is 0x05 and I've found a web site which has allowed me to enter the details of the CRC (Polynomial 0x131) and get the 0x05 result. http://www.sunshine2k.de/coding/javascript/crc/crc_js.html
    Basically I select "Input Reflected" and "Output reflected" put in a custom 8 bit polynomial of 0x31 and enter the data string:
    0x10 0x92 0xc8 0x72 0x03 0x08 0x00
    Result 0x05
     
    I'll paste in some test code here. It's very repetitive as I try to calculate a CRC for 1 byte, 2, 3, 4, 5, 6, 7 and the full One Wire ID including the CRC in the One Wire device so it should sum to zero. Only the single byte is summed correctly. I'd thought I must be loading the bytes incorrectly into the FIFO but the documentation states:
     
    "The input data is fed to the CRCDATL and CRCDATH registers. Depending upon the configuration
    of the DWIDTH bits, the width of CRCDATL and CRCDATH registers is configured.
    For data width less than or equal to 16 bits, only the CRCDATL register has to be used and any
    writes to the CRCDATH register will be ignored."
     
    The test code (this forum is making a mess of indentation):

        uint16_t  crc_sum;

            CRCCON1bits.CRCEN   = 0;          //DISABLED;
            CRCCON1bits.CSIDL   = 1;          // Stop in Idle mode
        CRCCON1bits.CRCISEL = 0;          // Interrupt when CRC Finished
        CRCCON1bits.LENDIAN = 1;          // One Wire is Little Endian (I think ;-)
            CRCCON2bits.PLEN    = 7;          // 8th Order Polynomial
            CRCCON2bits.DWIDTH  = 7;          // Working on 8 bit bytes        
        
            CRCXORL = 0x131;                  // polynomial X^8 + X^5 + X^4 + X^0  = 0b 1 0011 0001
            CRCXORH = 0x00;
        
        /*
         * Test the CRC of a single byte
         */
            CRCWDATH = 0;                     // Zero the result before we start
            CRCWDATL = 0;
            
        IFS4bits.CRCIF      = 0;          // Clear the ISR Flag
            CRCCON1bits.CRCEN   = 1;          // Enable the CRC Engine

        CRCDATL             = 0x10;       // As a test CRC a single byte
        
        CRCCON1bits.CRCGO   = 1;          // Start CRC

        while (!IFS4bits.CRCIF)           // Spin waiting for completion
            Nop();
            
        IFS4bits.CRCIF = 0;               // Clear the ISR Flag

            crc_sum = CRCWDATL;
        if (crc_sum == 0xB9) {
            LOG_D("One Byte CRC - Good\n\r");
        } else {
            LOG_E("One Byte CRC - Bad (0x%x != 0xB9)\n\r", crc_sum);
        }
            CRCCON1bits.CRCEN   = 0;          // Disable the CRC Engine

        /*
         * Test the CRC of a two bytes
         */
        delay(mSeconds, 1);
            CRCWDATH = 0;                     // Zero the result before we start
            CRCWDATL = 0;
            
        IFS4bits.CRCIF      = 0;          // Clear the ISR Flag
            CRCCON1bits.CRCEN   = 1;          // Enable the CRC Engine

        CRCDATL             = 0x10;       // Load two bytes
        CRCDATL             = 0x92;
        
        CRCCON1bits.CRCGO   = 1;          // Start CRC

        while (!IFS4bits.CRCIF)           // Spin waiting for completion
            Nop();
            
        IFS4bits.CRCIF = 0;               // Clear the ISR Flag

            crc_sum = CRCWDATL;
        if(crc_sum == 0x82) {
            LOG_D("Two Byte CRC - Good\n\r");
        } else {
            LOG_E("Two Byte CRC - Bad (0x%x != 0x82)\n\r", crc_sum);
        }
            CRCCON1bits.CRCEN   = 0;          // Disable the CRC Engine

        /*
         * Test the CRC of a three bytes
         */
        delay(mSeconds, 1);
            CRCWDATH = 0;                     // Zero the result before we start
            CRCWDATL = 0;
            
        IFS4bits.CRCIF      = 0;          // Clear the ISR Flag
            CRCCON1bits.CRCEN   = 1;          // Enable the CRC Engine

        CRCDATL             = 0x10;       // Load three bytes
        CRCDATL             = 0x92;
        CRCDATL             = 0xc8;
        
        CRCCON1bits.CRCGO   = 1;          // Start CRC

        while (!IFS4bits.CRCIF)           // Spin waiting for completion
            Nop();
            
        IFS4bits.CRCIF = 0;               // Clear the ISR Flag

            crc_sum = CRCWDATL;
        if(crc_sum == 0x08) {
            LOG_D("Three Byte CRC - Good\n\r");
        } else {
            LOG_E("Three Byte CRC - Bad (0x%x != 0x08)\n\r", crc_sum);
        }
            CRCCON1bits.CRCEN   = 0;          // Disable the CRC Engine

        /*
         * Test the CRC of a four bytes
         */
        delay(mSeconds, 1);
            CRCWDATH = 0;                     // Zero the result before we start
            CRCWDATL = 0;
            
        IFS4bits.CRCIF      = 0;          // Clear the ISR Flag
            CRCCON1bits.CRCEN   = 1;          // Enable the CRC Engine

        CRCDATL             = 0x10;       // Load four bytes
        CRCDATL             = 0x92;
        CRCDATL             = 0xc8;
        CRCDATL             = 0x72;
        
        CRCCON1bits.CRCGO   = 1;          // Start CRC

        while (!IFS4bits.CRCIF)           // Spin waiting for completion
            Nop();
            
        IFS4bits.CRCIF = 0;               // Clear the ISR Flag

            crc_sum = CRCWDATL;
        if(crc_sum == 0x9B) {
            LOG_D("Four Byte CRC - Good\n\r");
        } else {
            LOG_E("Four Byte CRC - Bad (0x%x != 0x9B)\n\r", crc_sum);
        }
            CRCCON1bits.CRCEN   = 0;          // Disable the CRC Engine

        /*
         * Test the CRC of a five bytes
         */
        delay(mSeconds, 1);
            CRCWDATH = 0;                     // Zero the result before we start
            CRCWDATL = 0;
            
        IFS4bits.CRCIF      = 0;          // Clear the ISR Flag
            CRCCON1bits.CRCEN   = 1;          // Enable the CRC Engine

        CRCDATL             = 0x10;       // Load five bytes
        CRCDATL             = 0x92;
        CRCDATL             = 0xc8;
        CRCDATL             = 0x72;
        CRCDATL             = 0x03;
        
        CRCCON1bits.CRCGO   = 1;          // Start CRC

        while (!IFS4bits.CRCIF)           // Spin waiting for completion
            Nop();
            
        IFS4bits.CRCIF = 0;               // Clear the ISR Flag

            crc_sum = CRCWDATL;
        if(crc_sum == 0x94) {
            LOG_D("Five Byte CRC - Good\n\r");
        } else {
            LOG_E("Five Byte CRC - Bad (0x%x != 0x94)\n\r", crc_sum);
        }
            CRCCON1bits.CRCEN   = 0;          // Disable the CRC Engine

        /*
         * Test the CRC of a six bytes
         */
        delay(mSeconds, 1);
            CRCWDATH = 0;                     // Zero the result before we start
            CRCWDATL = 0;
            
        IFS4bits.CRCIF      = 0;          // Clear the ISR Flag
            CRCCON1bits.CRCEN   = 1;          // Enable the CRC Engine

        CRCDATL             = 0x10;       // Load six bytes
        CRCDATL             = 0x92;
        CRCDATL             = 0xc8;
        CRCDATL             = 0x72;
        CRCDATL             = 0x03;
        CRCDATL             = 0x08;
        
        CRCCON1bits.CRCGO   = 1;          // Start CRC

        while (!IFS4bits.CRCIF)           // Spin waiting for completion
            Nop();
            
        IFS4bits.CRCIF = 0;               // Clear the ISR Flag

            crc_sum = CRCWDATL;
        if(crc_sum == 0xBE) {
            LOG_D("Six Byte CRC - Good\n\r");
        } else {
            LOG_E("Six Byte CRC - Bad (0x%x != 0xBE)\n\r", crc_sum);
        }
            CRCCON1bits.CRCEN   = 0;          // Disable the CRC Engine

        /*
         * Test the CRC of a seven bytes
         */
        delay(mSeconds, 1);
            CRCWDATH = 0;                     // Zero the result before we start
            CRCWDATL = 0;
            
        IFS4bits.CRCIF      = 0;          // Clear the ISR Flag
            CRCCON1bits.CRCEN   = 1;          // Enable the CRC Engine

        CRCDATL             = 0x10;       // Load seven bytes
        CRCDATL             = 0x92;
        CRCDATL             = 0xc8;
        CRCDATL             = 0x72;
        CRCDATL             = 0x03;
        CRCDATL             = 0x08;
        CRCDATL             = 0x00;
        
        CRCCON1bits.CRCGO   = 1;          // Start CRC

        while (!IFS4bits.CRCIF)           // Spin waiting for completion
            Nop();
            
        IFS4bits.CRCIF = 0;               // Clear the ISR Flag

            crc_sum = CRCWDATL;
        if(crc_sum == 0xA0) {
            LOG_D("Seven Byte CRC - Good\n\r");
        } else {
            LOG_E("Seven Byte CRC - Bad (0x%x != 0xA0)\n\r", crc_sum);
        }
            CRCCON1bits.CRCEN   = 0;          // Disable the CRC Engine

        /*
         * Test the CRC of a full OneWire ID Plus CRC (Eight bytes)
         */
        delay(mSeconds, 1);
            CRCWDATH = 0;                     // Zero the result before we start
            CRCWDATL = 0;
            
        IFS4bits.CRCIF      = 0;          // Clear the ISR Flag
            CRCCON1bits.CRCEN   = 1;          // Enable the CRC Engine

        CRCDATL             = 0x10;       // Load eight bytes
        CRCDATL             = 0x92;
        CRCDATL             = 0xc8;
        CRCDATL             = 0x72;
        CRCDATL             = 0x03;
        CRCDATL             = 0x08;
        CRCDATL             = 0x00;
        CRCDATL             = 0x05;
        
        CRCCON1bits.CRCGO   = 1;          // Start CRC

        while (!IFS4bits.CRCIF)           // Spin waiting for completion
            Nop();
            
        IFS4bits.CRCIF = 0;               // Clear the ISR Flag

            crc_sum = CRCWDATL;
        if(crc_sum == 0x00) {
            LOG_D("OneWire ID CRC - Good\n\r");
        } else {
            LOG_E("OneWire ID CRC - Bad (0x%x != 0x00)\n\r", crc_sum);
        }
            CRCCON1bits.CRCEN   = 0;          // Disable the CRC Engine

     
    #6
    arigead
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2011/02/07 06:58:31
    • Location: 0
    • Status: offline
    Re: dsPIC33EP256MU806 When is the CRC Module's summation finished? 2018/05/16 13:30:09 (permalink)
    0
    Sorry that code I inserted is unreadable because the indentation is completely distorted. I guess this forum ain't really about code as such so it's understandable. And the IDE I'm using (MPLAB-X) probably has it's own way of doing things.
     
    #7
    qɥb
    Monolothic Member
    • Total Posts : 2641
    • Reward points : 0
    • Joined: 2017/09/09 05:07:30
    • Location: Jupiter
    • Status: online
    Re: dsPIC33EP256MU806 When is the CRC Module's summation finished? 2018/05/16 13:37:45 (permalink)
    0
    Indentation doesn't look too bad on my screen.
    What the forum cannot handle is raw TAB characters. It requires indentation to use spaces.
     

    This forum is mis-configured so it only works correctly if you access it via https protocol.
    The Microchip website links to it using http protocol. Will they ever catch on?
    PicForum "it just works"
    #8
    du00000001
    Just Some Member
    • Total Posts : 1891
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: dsPIC33EP256MU806 When is the CRC Module's summation finished? 2018/05/16 13:56:24 (permalink)
    0
    Oh yes - CRC is some difficult matter. And while the websites exhibit some "intelligence" on their own, "dumb hardware" might not do so:
    1. When calculating an 8-Bit wide CRC, the polynom term cannot be wider than 8 bits. (Expected to be 0x31 in your case.) The most significant term represents the incoming bit and is NOT part of the value to be written.
    2. If you have to "reflect" the input AND output for the online calculator, try bit-mirroring the polynom value instead: 0x31 ==> 0x8C ! (This has to do with the direction of shifting - and is one of the most common problems when implementing a bit-shift algorithm.)
    Regarding the IF: check the datasheet and your config: there are 2 alternate sources for the IF: input buffer empty or counter exhausted. I expect "CRC calculation terminated" to result from some other condition. The ages-old RTFM! still holds.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #9
    davekw7x
    Entropy++
    • Total Posts : 1405
    • Reward points : 0
    • Joined: 2012/01/16 12:01:07
    • Location: Left Coast, USA
    • Status: offline
    Re: dsPIC33EP256MU806 When is the CRC Module's summation finished? 2018/05/17 15:30:20 (permalink)
    5 (3)
    [Disclaimer]
    I don't have a dsPIC33EP256MU806 to test with, bit I was able to dig up a test platform for a dsPIC33EP512MU810, which I used in a project some years ago.
    The reason that I mention this is because, in my experience, different MCUs with CRC modules have different functionality, and direct personal experience with, say, a PIC24FJ1024GB610 does not exactly carry over to, say a dsPIC33EP512MU810 or a PIC16F1619.

    To keep things simple, I'll give an example with straight calculations, no interrupts or any other fancy stuff.

    Bottom line for the disclaimer: I am telling what works for me with a dsPIC33EP512MU810.  Since there is no CRC errata that I know of for any chips in this family, I would be shocked if there is any different functionality for a dsPIC33EP256MU806.
    [/Disclaimer]

    OK, here are some "issues" with the O.P. code

    This is for an 8-bit CRC being fed 8 bits at a time.  This is the simplest case, and there are no problems with odd numbers of bytes or other things that make other cases somewhat more problematic.
    So: This is absolutely wrong:

        CRCDATL = 0x10;       // As a test CRC a single byte

    CRCDATL is a 16-bit register.  The compiler generates code that writes 16 bits to CRCDATL: One byte is your data (that's good), and an extra byte that results from promoting your data to a 16-bit integer (that's bad---Very Bad).  So every place in your code where you have an assignment to CRCDATL, the code must be changed so that it only writes eight bits

    .
    One way to do this is to define a pointer.  Maybe like this:

        uint8_t *dest = (uint8_t *)&CRCDATL;


    This will not change for the duration of the calculation.


    Now, instead of the assignment statement to CRCDATL, you would have

        *dest = 0x10; // Or whatever


    Secondly, I don't know where the guy who wrote the thing in the Family Reference Manual (about the CRCGO bit resetting itself) got the information or what chip that refers to, but I absolutely, positively, guarandamtee that it is not true for this chip (or any other Microchip MPU that I have ever used).  GO stays set until you clear it.  At least that's my experience.  I'll talk about that in a minute.

    Thirdly, when you have shifted all of the data bytes through the CRC engine, the last byte is still in the internal CRC shift register, which is not visible to the outside world.  (This may or may not be true for other chips, but is definitely true for this chip.)

     
    So, after all of the data have been exhausted, then you write an extra eight bits to shift all of the bits to the CRCWDATL register so that you can retrieve it for your use.  I just write eight zero bits.


    That is, after all data have been shifted, there is another statement like this

        *dest = 0x00; /* Do this to shift the last word out of the CRC shift register */

    Bottom line for calculations: After your program has transferred all of the bytes to the CRC register, and the final zero byte, wait until TRMT is 1, then clear the GO bit and read the value of CRCWDATL.  Period.  Full Stop.

    Finally (for now), we gotta talk about the the "LENDIAN" thing.  This is a convenience, not found on older chips, that allows you to feed data bytes in the same order that they were calculated and have them shifted into the CRC engine LSB first.  Nothing is changed in the way that the CRC is calculated.  The final result in the CRC registers is the true, mathematical CRC.
    This is important in the following case (the case we are testing: MAXIM CRC stuff, as document in Maxim Application Note AN27)
    We have seven data bytes.  We calculate the CRC of those bytes with LENDIAN=1, and we want to append a value to the data stream so that the total CRC for the resulting eight bytes is zero.


    You have to reverse the bits of the mathematical CRC from the CRC module and put that byte into the array, since those bits will be reversed when they get shifted into the CRC register.  Really.  You have to reverse the bits (if and only if LENDIAN is 1).

    The other end doesn't know or care how you calculated the byte that you appended to the data.  It simply calculates the CRC for all eight bytes and expects to get zero.  (That is, assuming there is some higher level protocol that tells the other end where the data stream starts and stops.)

    I have attached a part of the test program that uses your data.  I used your seven data bytes.  Just to illustrate partial CRC results, I did a separate calculation using one byte, two bytes, three, bytes, etc.  For purposes of illustration, the CRC routine does not reverse the results before returning.  I wanted to show what the CRC engine calculates, and then show the reversed value. The only one of those reversed values that I used is the one from the 7-byte sequence.

    Finally, I took the result from the 7-byte calculation, appended its bit-reversed value to the seven original data bytes and show the CRC results for those eight.

    Here's the output:
     
    Compiled on May 17 2018 at 14:37:24 PDT with XC16 version 1034
     
    The original data:  0x10 0x92 0xC8 0x72 0x03 0x08 0x00
     
    Calculating CRC for number of bytes = 1,2,...,7
     
      Number of  Hardware   Bit-Reversed
        Bytes      CRC          CRC
      ----------------------------------
          1        0xB9         0x9D
          2        0x82         0x41
          3        0x08         0x10
          4        0x9B         0xD9
          5        0x94         0x29
          6        0xBE         0x7D
          7        0xA0         0x05

    Appended the (reversed) 7-byte CRC value to the original data.
    The entire stream:  0x10 0x92 0xC8 0x72 0x03 0x08 0x00 0x05

    Calculating CRC for the entire eight bytes
    Hardware CRC Value = 0x00, reversed = 0x00


    Regards,


    Dave


    post edited by davekw7x - 2018/05/18 06:38:20

    Sometimes I just can't help myself...
    #10
    arigead
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2011/02/07 06:58:31
    • Location: 0
    • Status: offline
    Re: dsPIC33EP256MU806 When is the CRC Module's summation finished? 2018/05/19 12:09:32 (permalink)
    0
    Thank you du00000001 for responding and I know that it's unlikely that I'm right but I do think that there's an error in the document describing CRC, which isn't in the Errata. The fact that davekw7x confirms makes me think perhaps I found something where RTFM just ain't going to work because the manual is wrong.
    It's just the sentence: "When the calculation is complete, the module will clear the GO bit and set the CRC Interrupt Flag (if CRCISEL = 0)." the sentence seems quite clear and straight forward but it ain't what happens.
     
    Anyhow thanks to davekw7x it's all working now! Thanks again for your response.
     
    #11
    arigead
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2011/02/07 06:58:31
    • Location: 0
    • Status: offline
    Re: dsPIC33EP256MU806 When is the CRC Module's summation finished? 2018/05/19 12:22:55 (permalink)
    3 (1)
    davekw7x I owe you a number of tasty beverages for that response. It was the simplest of things but I'd never have twigged it. Your point about the compiler writing a 16 bit value, to a 16 bit register, when I was trying to write an 8 bit byte was the key. That and the finishing off with a 0x00 byte to finish th8ings off.
    Those two points are why when I tried to do a CRC of a single byte that was working because I was writing the 8 bit byte followed by the 0x00, OK completely by accident. So that's all it took, force compiler to write 8 bits and append a zero, but like I say I'm sure I'd not have twigged it without your help.
     
    thanks a million for your help!
     
    #12
    marcov
    Senior Member
    • Total Posts : 170
    • Reward points : 0
    • Joined: 2006/10/08 01:59:40
    • Location: Eindhoven, NL.
    • Status: offline
    Re: dsPIC33EP256MU806 When is the CRC Module's summation finished? 2018/05/20 06:30:43 (permalink)
    0
    Note while there is no silicon problem, iirc the 8-bit CRC code of the peripheral libraries is wrong (needs an additional zero shifted in near the end to correctly shift the value out)
     
    (hmm, dug out my own post, and there seems not a whole lot of confirmation from others that it is a bug. OTOH it describes fairly well what I thought the bug was: http://www.microchip.com/forums/m791694.aspx
     
    The peripheral library source is a good place to start anyway.
    )
    post edited by marcov - 2018/05/20 06:36:46
    #13
    Jump to:
    © 2018 APG vNext Commercial Version 4.5