Cálculo de CRC diferente para IC

Trato de leer los datos del sensor AS5047U ( https://ams.com/documents/20143/36005/AS5047U_DS000637_1-00.pdf/8639418f-6c3a-1624-4e6f-18f52c962099 ) sobre SPI, pero de alguna manera mi CRC siempre es diferente a la del sensor. Puedo leer el valor de posición correcto y el valor de crc del sensor y el crc permanece igual para el mismo valor de posición, así que creo que obtuve el marco correcto para crc.

Obtuve, por ejemplo, los siguientes valores de mi cálculo de crc y el crc proporcionado por el sensor (spi1.data son los datos recibidos sobre spi, spi.cmd son los datos enviados):

ingrese la descripción de la imagen aquí

¿Alguna idea de lo que podría estar mal aquí?

Procesamiento SPI crc:

rx_spi_16(&spi1.data[0],&spi1.cmd[0],2);

pos_sensor.crc = (spi1.data[1] >> 8);

uint8_t crc = crc8((uint8_t *)&spi1.data[0],2);

Comando TX para enviar (modo de 16 bits):

spi1.cmd[0] = 0x7FFF;
spi1.cmd[1] = 0;

Cálculo de CRC:

uint8_t crc8(uint8_t *message ,uint8_t length)
{
    uint32_t crc;
    int16_t i,bit;

    crc = 0xff;
    for ( i=0 ; i<length ; i++ )
    {
        crc ^= message[i];
        for ( bit=0 ; bit<8 ; bit++)
        {
            if ( (crc & 0x80)!=0 )
            {
                crc <<= 1;
                crc ^= 0x1D;
            }
            else
            {
                crc <<= 1;
            }
        }
    }

    return (~crc) & 0xFF;
}
El polinomio es correcto. Lo que me desconcierta es que el chip quiere transferir el byte alto primero y el byte bajo al final en un marco de datos de 16 bits. Debe saber en qué orden su MCU lo almacena en la memoria, cuando lo direcciona como bytes. Los chips ARM estándar tienen el byte bajo en la dirección 0. Pero no explica la diferencia. Compruebe si debe tomar primero el bit más significativo o el menos significativo, o enmascarar algunos bits que no son de datos.
De hecho, estoy peleando exactamente con el mismo chip por la misma razón. También voy a hacer eco de @Justme en el sentido de que supongo que probablemente tengas byte endianness al revés. Dicho esto, incluso con el byte endian correcto, el CRC que regresa del chip no está de acuerdo con mis cálculos.
Por ejemplo, al devolver 0x03 0xC2 (leyendo el registro DIA) calcula un CRC de 0x2A, mientras que el CRC esperado es 0x65.

Respuestas (2)

Después de un poco de fuerza bruta, resulta (como se sospechaba) que la hoja de datos miente. El AS5047U sí lo usa 0x1Dcomo su polinomio, pero, a diferencia de J1850, el valor inicial es 0xB7y el valor xor final es 0x00. Puede verificar fácilmente ingresando esos valores aquí: http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

Editar: Acabo de recibir un ejemplo de código del proveedor y contiene este encantador bocado:

    // The CRC Implementation of the device is not fully compatible to the CRC8_SAE_J1850-standard.
    // It requires to put in 0x00 as first byte before the communication starts.
    // So, the crc-initial value is crcLut[0 ^ 0xff] which is equal to 0xC4

Lo que este comentario (mal) intenta explicar es que el valor inicial es 0xC4, con un valor final aún de 0xFF. He respondido al proveedor con un correo electrónico redactado enérgicamente.

Gracias Benjamin, sabía que algo andaba mal aquí;)

para su información, esto ya se modificó en la hoja de datos AS5147U. (Mismo sensor solo calificado para automoción) Se cambiará en el AS5047U lo antes posible.

Enlace a la hoja de datos de AS5147U: https://ams.com/documents/20143/36005/AS5147U_AS5247U_DS000639_4-00.pdf

saludos j

Si está diciendo que la hoja de datos es incorrecta, ayudaría si pudiera decirlo explícitamente. ¿Existe tal vez una fe de erratas que incluya esto?
Cálculo de CRC diferente para IC
RespuestasAquíPolítica de privacidad1y, 0v