cancel
Showing results for 
Search instead for 
Did you mean: 

Test F7 SPI CRC Generation

Ba5tian
Associate II

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?

12 REPLIES 12
Mike_ST
ST Employee

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 ?

>>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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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.

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.

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
Associate II

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 */
}

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

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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.