STM32U585 SPI CRC issue

[DFell.1]

Hello all,

I am currently trying to enable the CRC SPI (CRC-16/CCITT-FALSE) on my project, but I can't make it work. 

You can found bellow the SPI configuration set on CubeMx

Here is the message read back on my logic analyser, in yellow (0x0C52) you'll found the CRC computed by the uC.

However with the configuration set I am expecting to get this value: 0xE1F0

From then I suggest that my CRC SPI configuration was not set properly and from an online CRC calculator (https://crccalc.com/) I have check if I could found a match with an another algorithm, unfortunatly I have made no match.

Does any one have a solution to this issue.

 

Many thanks

 

[Tesla DeLorean]

What would be far more helpful would be the output code, and the registers, especially the CRC register, as you output each of the bytes.

A quick C coding got me 0x1F1F, so no idea where you pulled any of your numbers or expectations.

An for extra entertainment, I ran it thru crccalc.com

#include <windows.h>
#include <stdio.h>

typedef unsigned char uint8_t;
typedef unsigned short uint16_t;

uint16_t crc16(uint16_t crc, uint8_t byte)
{
 int i;

 crc = crc ^ ((uint16_t)byte << 8);

 for(i=0; i<8; i++)
 if (crc & 0x8000)
 crc = (crc << 1) ^ 0x1021;
 else
 crc <<= 1;

 return(crc);
}

int main(int argc, char **argv)
{
 uint16_t crc = 0xFFFF;

 crc = crc16(crc, 0x00);
 crc = crc16(crc, 0x11);

 printf("%04X\n", crc);

 return(1);
}

[DFell.1]

Thank you for your response.

First what do you mean by "the output code" ? If you refering to the code error send from the HAL_SPI_TransmitReceive command this one is currently HAL_ERROR with the CRC error code fault.

Concerning the SPI register this is the register before the transmission

and bellow the SPI register right after the transmission

 

 

 

[Tesla DeLorean]

By output code I mean what's transacting with the SPI peripheral hardware. The STM32 CRC for SPI has to be initialized, and then transitioned so it sends the CRC bytes rather than data bytes. It typically has no idea where the data stops and the check bytes start.

On the receive side it typically to just pull the data in and the nature of the CRC is to remainder to zero if a copy of the check bytes is passed thru the CRC, and then you "Zero Check" the CRC bytes after the DATA+CRC bytes have processed. But this too has corollaries, as it depends on shift direction, endianness of the chosen implementation/protocol.

ST's general solution to everything is a poor fit to specific / problem things..

[waclawek.jan]

Initial value of the SPI CRC is 0. I don't have the RM at hand now, but I believe that it says so.

JW

[Tesla DeLorean]

I haven't dug into the U5 that deep, but the OP's screen shot shows "Tx Crc Initialization - All One Pattern"

Going to need to walk the transfer and peripheral state one byte at a time to confirm operation and expectations.

 

[waclawek.jan]

Okay, the 'U5 SPI is yet again more complicated, and the documentation is... well... "ST-style". I faintly recall @Uwe Bonnes writing about it recently. And okay, I see, while there's no way to set an arbitrary initialization value, there's a new TCRCINI bit which allows to set the "all ones" as alternative to "all zeros".

And then there's also this:

JW