Same CRC routine returns different results... :o

[ricko_uk]

Hi,
this is a weird one...

I have the same CRC routine (literally cut and paste) on a PIC32MZ and an Arduino Uno (which I am using just to check general functionality.

On the arduino the CRC routine returns a number (which I can see on the bus with the logic analyser is correct) and when I parse the received data that value and the entire stream is also correct (the receive buffer on the PIC32 is an exact copy of the sent buffer from the Arduino).

But when I calculate the CRC on the PIC32 using the same cut-and-paste routine using the same data input it returns a different value...

For example:
- this is the one calculated on the arduino...  0xCE9C3870
- this is the one calculate don the PIC32....   0x24637E70

The only thing that is strange is that the least significant byte of the CRC is always calculated correctly on the PIC32 but only that byte, not the other 3.

Any idea what could cause that?

The Arduino sketch, including the CRC routine is this:

Code: [Select]

#include <SPI.h>

const int SSpin = 10;
const int SBusy = 9;

#define SPI_CMD__LOAD_START           0x01

SPISettings settingsA(100000, MSBFIRST, SPI_MODE2);
uint8_t buffer[10] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

void setup() {
  // put your setup code here, to run once:
  pinMode (SSpin, OUTPUT);
  pinMode (SBusy, INPUT);
  SPI.begin();
}


uint32_t rc_crc32(uint32_t crc, const char *buf, size_t len)
{
  static uint32_t table[256];
  static int have_table = 0;
  uint32_t rem;
  uint8_t octet;
  int i, j;
  const char *p, *q;
 
  /* This check is not thread safe; there is no mutex. */
  if (have_table == 0) {
    /* Calculate CRC table. */
    for (i = 0; i < 256; i++) {
      rem = i;  /* remainder from polynomial division */
      for (j = 0; j < 8; j++) {
        if (rem & 1) {
          rem >>= 1;
          rem ^= 0xedb88320;
        } else
          rem >>= 1;
      }
      table[i] = rem;
    }
    have_table = 1;
  }
 
  crc = ~crc;
  q = buf + len;
  for (p = buf; p < q; p++) {
    octet = *p;  /* Cast to unsigned octet. */
    crc = (crc >> 8) ^ table[(crc & 0xff) ^ octet];
  }
  return ~crc;
}

void loop() {

  uint32_t tmpCRC = 0;
 
    SPI.beginTransaction(settingsA);
 
  while (1)
  {
    buffer[0] = SPI_CMD__LOAD_START;    //cmd
    buffer[1] = 0xAA;   //cmd option
    buffer[2] = 0x55;   //cmd option
    buffer[3] = 1;      //data length
    buffer[4] = 'A';   //data

    tmpCRC = rc_crc32(0, (char*) buffer, 5);

    buffer[5] = tmpCRC >> 3;  //CRC1
    buffer[6] = tmpCRC >> 2; //CRC2
    buffer[7] = tmpCRC >> 1;  //CRC3
    buffer[8] = tmpCRC;  //CRC4
   
    digitalWrite (SSpin, LOW);
    //SPI.transfer('A');
    SPI.transfer(buffer, 9);
    digitalWrite (SSpin, HIGH);
    delay(1000);
  }
}



The Pic32 code is below. The structParsedMessage.ui32_CRC corresponds to the sent CRC AND to the CRC I see on the SPI bus with the logic analyser:

Code: [Select]

        case MESSAGE_RECEIVED:
        {
            structParsedMessage.ui32_CRC = aui8_RxBuffer[ui8_RxBufferBytesCount - 4];
            structParsedMessage.ui32_CRC = structParsedMessage.ui32_CRC << 8;                   
            structParsedMessage.ui32_CRC = structParsedMessage.ui32_CRC | aui8_RxBuffer[ui8_RxBufferBytesCount - 3];
            structParsedMessage.ui32_CRC = structParsedMessage.ui32_CRC << 8;                   
            structParsedMessage.ui32_CRC = structParsedMessage.ui32_CRC | aui8_RxBuffer[ui8_RxBufferBytesCount - 2];
            structParsedMessage.ui32_CRC = structParsedMessage.ui32_CRC << 8;                   
            structParsedMessage.ui32_CRC = structParsedMessage.ui32_CRC | aui8_RxBuffer[ui8_RxBufferBytesCount - 1];
           
            //check CRC
            uint32_t tmpCRC = rc_crc32(0, (char*) aui8_RxBuffer, 5); //(ui8_RxBufferBytesCount - 4));
            if (tmpCRC == structParsedMessage.ui32_CRC)
            {
                //CRC match so message received correctly
                _nop();
            }
            else
            {
                //CRC did not match
                _nop();
            }
            break;
        }


Thank you

[SiliconWizard]

Do you mean that the rc_crc32() on the PIC32 is the exact same code as the one used on Arduino?

[oPossum]

Try this change on the Arduino...

Code: [Select]

         rem ^= 0xedb88320ULL;


[ricko_uk]

Thank you SiliconWizzard,
It is included in the Arduino code (the first code snippet in the OP).

It is this part:

Code: [Select]


uint32_t rc_crc32(uint32_t crc, const char *buf, size_t len)
{
  static uint32_t table[256];
  static int have_table = 0;
  uint32_t rem;
  uint8_t octet;
  int i, j;
  const char *p, *q;
 
  /* This check is not thread safe; there is no mutex. */
  if (have_table == 0) {
    /* Calculate CRC table. */
    for (i = 0; i < 256; i++) {
      rem = i;  /* remainder from polynomial division */
      for (j = 0; j < 8; j++) {
        if (rem & 1) {
          rem >>= 1;
          rem ^= 0xedb88320;
        } else
          rem >>= 1;
      }
      table[i] = rem;
    }
    have_table = 1;
  }
 
  crc = ~crc;
  q = buf + len;
  for (p = buf; p < q; p++) {
    octet = *p;  /* Cast to unsigned octet. */
    crc = (crc >> 8) ^ table[(crc & 0xff) ^ octet];
  }
  return ~crc;
}



[Kjelt]

Not sure, no time to check but is the endianess of both uc's the same ?
This has bitten me quite often with security algorithms in the past.

[ricko_uk]

thank you oPossum,
I tried that just now but the result is the same. Any other suggestions?

[ricko_uk]

Thank you Kjelt,
I checked and both Arduino Uno (ATMega 328P) and PIC32MZ are both little endian.

[ricko_uk]

@SiliconWizzard,
yes they are both the same code, literally cut and paste. That's why it doesn't make much sense that they return different results.

[oPossum]

Is the generated CRC table the same on both?

[ricko_uk]

@oPossum,
Unfortunately on the Arduino there is no way to debug or see/output the table apart from the serial port but at the moment all the serial to USB I have are connected to running experiments I cannot stop.

[SiliconWizard]

I don't understand this part:

Code: [Select]

    buffer[5] = tmpCRC >> 3;  //CRC1
    buffer[6] = tmpCRC >> 2; //CRC2
    buffer[7] = tmpCRC >> 1;  //CRC3
    buffer[8] = tmpCRC;  //CRC4
It doesn't look right to me.

[ricko_uk]

In front of the PC for almost 16 hours so maybe I am doing something really stupid... But the idea is to split 32-bit CRC into 4 bytes and load it into the buffer to be sent.

[SiliconWizard]

In front of the PC for almost 16 hours so maybe I am doing something really stupid... But the idea is to split 32-bit CRC into 4 bytes and load it into the buffer to be sent.

I thought that was the intent. But it won't work. You're right shifting the CRC by 3, then 2, then 1 bit, then 0 bit. Only the last (LSByte) will be right. I think this is your problem here.

[ricko_uk]

      
I noticed that after posting it. I was about to reply how stupid that error was but u replied first.

Thank you as always!

[DavidAlfa]

You're overloading yourself! You need to close everything and go for a walk!
My advice is to go to a nearby quarry and ask for 1-day job breaking stone with hand tools.
After that, take a shower and a long nap. 2-3 days later you will wake up like new!   

[ricko_uk]

David,
that sounds about right... it sounds like a holiday!   

[harerod]

So were you able to resolve the problem?

My five cents would have been:
Exactly the same source will yield different results, when compiler implementations vary.
With C, a classic would be sizeof(int).

Edit: grammar...

[Siwastaja]

Sounds like the result was identical but readout of the result from the micro was buggy, no?

[ricko_uk]

Siwastaja,
yes