Test F7 SPI CRC Generation

[Ba5tian]

Hello,

i have a programm which is sending 2bytes + 16bit CRC from SPI2.

There are two STM32F765 on my board. The test programm is generated with CubeIDE and only SPI2 initiallyzed.

One MCU is calculating the crc correct and the other is not correct.(Checked with an online crc calculation website)

polynom used: 0x9021

Result from MCU 1(correct): 0x08 0x06 0x24 0xDC

Result from MCU 2(not correct): 0x08 0x06 0x63 0xEE

I have checked the register before sending, they are equal.

After sending the registers are equal, the only differnce is in SPI2->DR where the calculated crc can be seen.

Regards,

Bastian

Is there a way to test if the processor hardware damaged?

[Mike_ST]

Would be bad luck if the SPI CRC computation unit was broken.

A software with predefined result would say.

Is it same binary running on both processors ?

[Ba5tian]

Same binary on both processors.

I may have plugged in and out the board while powered. SPI Lines are "protected" with ferrite und capacitor, maybe induction damaged the spi.

[Tesla DeLorean]

>>SPI2->DR where the calculated crc can be seen.

Not sure that's how this works.

There's a separate register you can inspect, but more generally you push the CRC bytes through and then the "check" is that is zeros out the residual

Inspect SPIx_RXCRCR as that's non intrusive, and don't look at the register bank in the debugger. Read the value in your own code, and print it to a telemetry/diagnostic stream.

[Ba5tian]

I can see that the crc is wrong there is a logic analyser connected.

MCU 1 and MCU 3 transmit data to MCU 3. MCU 1 is calculating the correct crc .

I have tested my self designed boards and nucleo board. On the nucleo ones i can see the crc after transmit in DR register. The "damaged" self designed has the wrong crc in DR register after transmit.

[waclawek.jan]

It's very unlikely that an internal circuit would get damaged; it's probably a software bug.

Stop down the program to bare minimum exhibiting the problem and post it.

JW

[Ba5tian]

After noticing the error i made a minimum programm with CubeIde which only contained SPI2.

On controller 2 the crc is calculated wrong and controller 1 is corret. I only plugged the debugger from one controller to another.

I'm using a logic analyser to see the data.

#define PUT_DMA_BUFFER \
 __attribute__((section(".dtcm")))
 
PUT_DMA_BUFFER uint8_t arr_bTransmit[10];
PUT_DMA_BUFFER uint8_t arr_bReceive[10];
 
/* USER CODE END PFP */
 
/* Private user code ---------------------------------------------------------*/
/* USER CODE BEGIN 0 */
 
/* USER CODE END 0 */
 
/**
 * @brief The application entry point.
 * @retval int
 */
int main(void)
{
 /* USER CODE BEGIN 1 */
 
 /* USER CODE END 1 */
 
 /* Enable I-Cache---------------------------------------------------------*/
 SCB_EnableICache();
 
 /* Enable D-Cache---------------------------------------------------------*/
 SCB_EnableDCache();
 
 /* MCU Configuration--------------------------------------------------------*/
 
 /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
 HAL_Init();
 
 /* USER CODE BEGIN Init */
 
 /* USER CODE END Init */
 
 /* Configure the system clock */
 SystemClock_Config();
 
 /* USER CODE BEGIN SysInit */
 
 /* USER CODE END SysInit */
 
 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_DMA_Init();
 MX_SPI2_Init();
 /* USER CODE BEGIN 2 */
 
 arr_bTransmit[0] = 0x08;
 arr_bTransmit[1] = 0x06;
 arr_bTransmit[2] = 0x05;
 arr_bTransmit[3] = 0x04;
 arr_bTransmit[4] = 0x03;
 arr_bTransmit[5] = 0x02;
 arr_bTransmit[6] = 0x01;
 arr_bTransmit[7] = 0x00;
 
 
 /* USER CODE END 2 */
 
 /* Infinite loop */
 /* USER CODE BEGIN WHILE */
 while (1)
 {
 
 
	 HAL_SPI_Transmit_DMA(&hspi2, arr_bTransmit, 2);
//	 HAL_SPI_TransmitReceive_DMA(&hspi2, arr_bTransmit, arr_bReceive, 2);
 
	 HAL_Delay(25);
 
 /* USER CODE END WHILE */
 
 /* USER CODE BEGIN 3 */
 }
 /* USER CODE END 3 */
}

[Tesla DeLorean]

The idea here would to be to present enough code, including initialization, that it could be rebuilt quickly/easily. That it would include diagnostic/self-check output, so absent a debugger the behaviour could be observed and reported.

[waclawek.jan]

So the same binary is in both controllers?

Try without using CRC transmit the correct sequence (i.e. transmit a fixed sequence of 4 bytes).

JW

[Ba5tian]

Yes, same binary in both controllers.

Sending 4 bytes including self calculated crc is always the same result. The 4 bytes are the same as in the buffer.

[waclawek.jan]

I am out of ideas.

As Clive said above, post the complete compilable minimal program so that the problem could be reproduced.

JW

[Ba5tian]

Hi,

we finally found the solution to the wrong spi crc.

Somtimes the crc got calcutated right and sometimes wrong.

All SPI Pins where used with port speed very high, after changing to medium the crc generation is working perfect.

Now we added 47Ohm resistors in the mosi, miso, ckl and nss line, changed the port speed back to very high and anabled the compensation cell. The crc is calculated right.

In conclusion i suspect that the internal powersupply can't deliver enough power to the spi peripheral.

[waclawek.jan]

Wow, this was unexpected.

Problems with high GPIO settings are usually related to reflections - one device "sees" more clicks than there were transmitted - that's why termination helps.

Thanks for coming back with the solution, this is very helpful.

JW