STM32... How can SPI cause a reset? Serious bug here.

[VK3DRB]

Hi.

I have a bug which is driving me nuts.

I am using an STM32L151RBT6A, programmed in C using STM32cubeIDE rev. 1.15.1.
The SPI drives two radios: CC1120 (FSK) and SX1276 (LoRa).
Wiring is correct as per the datasheets and separate chip selects are used for the SPI.

The STM32 resests (reset glitch form 3.0V to 0V) whenever I do an SPI operation, even if I have both radio chips in reset, or one in reset or none in reset.
I cannot see how this can occur. Power supplies are clean, no radios operating (no RF).
I rerouted the nSS pin to PB0 (cut track and wire-add wire) to separate the chip select to try to find out what is causing the reset.

I am under immense pressure to fix this bug within the next two days. If anyone spots anything here, please let me know. It will be much appreciated.

Code is here:



 u8 data=0;
  uint8_t receivedData = 0;

  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */

   HAL_Delay(500);

   HAL_GPIO_WritePin(nCS_SX1276,SET_PIN_HIGH);
   HAL_GPIO_WritePin(nCS_CC1120,SET_PIN_LOW);
   //HAL_GPIO_WritePin(nRESET_SX1276,SET_PIN_LOW);
   //HAL_GPIO_WritePin(nRESET_CC1120,SET_PIN_LOW);

   HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_RESET); // Set CS low on PB0, the rewired CS for the CC1120

   data = 0x30;   // Reset command for CC1120

   if (HAL_SPI_TransmitReceive(&hspi1, &data, &receivedData, 1, HAL_MAX_DELAY) != HAL_OK)  // THIS COMMAND CAUSES THE RESET OF THE STM32!!!
   {
      Error_Handler();
   }

   HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_SET); // Set CS high

  }
  /* USER CODE END 3 */

static void MX_SPI1_Init(void)
{

  /* USER CODE BEGIN SPI1_Init 0 */

  /* USER CODE END SPI1_Init 0 */

  /* USER CODE BEGIN SPI1_Init 1 */

  /* USER CODE END SPI1_Init 1 */
  /* SPI1 parameter configuration*/
  hspi1.Instance = SPI1;
  hspi1.Init.Mode = SPI_MODE_MASTER;
  hspi1.Init.Direction = SPI_DIRECTION_2LINES;
  hspi1.Init.DataSize = SPI_DATASIZE_8BIT;
  hspi1.Init.CLKPolarity = SPI_POLARITY_LOW;
  hspi1.Init.CLKPhase = SPI_PHASE_1EDGE;
  hspi1.Init.NSS = SPI_NSS_SOFT;
  hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_2;
  hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;
  hspi1.Init.TIMode = SPI_TIMODE_DISABLE;
  hspi1.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
  hspi1.Init.CRCPolynomial = 10;
  if (HAL_SPI_Init(&hspi1) != HAL_OK)
  {
    Error_Handler();
  }
  /* USER CODE BEGIN SPI1_Init 2 */

  /* USER CODE END SPI1_Init 2 */

}

[ataradov]

Does it also happen when you single step through the code? If so, can you  narrow down the place?

If you can't reproduce it with single stepping, define another GPIO and toggle it at different places along the code path inside the HAL_SPI_TransmitReceive().

[thm_w]

Can you be more specific, you are saying nReset (pin 7 of the MCU) is going from 3V to 0V without outside intervention? That doesn't really make sense.
Does 3V-MCU change at all when that happens?
Does it happen with the debugger disconnected? (maybe its wired incorrectly)

VDDA should not be tied to Vdd with a 10k resistor. Change that to 0R.

[ataradov]

That doesn't really make sense.

Reset pin is open drain (with  internal pull-up) and MCU itself can drive it low on a number of internal reset sources.

One of those sources is WDT. So, if WDT  is enabled, I would check the WDT timeout and the duration of a blocking loop in SPI.

And of course, check the reset reason. It will tell you exactly why reset has happened.

[VK3DRB]

Does it also happen when you single step through the code? If so, can you  narrow down the place?

If you can't reproduce it with single stepping, define another GPIO and toggle it at different places along the code path inside the HAL_SPI_TransmitReceive().

I found the line of code in stm32I1xx_hal_spi.c that crashed using debug, if that is any help...
 

  /* Transmit and Receive data in 8 Bit mode */
  else
  {
    if ((hspi->Init.Mode == SPI_MODE_SLAVE) || (initial_TxXferCount == 0x01U))
    {
      *((__IO uint8_t *)&hspi->Instance->DR) = (*hspi->pTxBuffPtr);  // STEPPING OVER THIS LINE OF CODE CAUSES THE RESET!
      hspi->pTxBuffPtr += sizeof(uint8_t);
      hspi->TxXferCount--;
    }

[ataradov]

Check the  reset reason. There is no obvious reason why this would cause the reset.

[VK3DRB]

Can you be more specific, you are saying nReset (pin 7 of the MCU) is going from 3V to 0V without outside intervention? That doesn't really make sense.
Does 3V-MCU change at all when that happens?
Does it happen with the debugger disconnected? (maybe its wired incorrectly)

VDDA should not be tied to Vdd with a 10k resistor. Change that to 0R.

Here is an image of the reset line when the glitch occurs.

Also, the 3V0-MCU is stable - no dropouts or noise.


Will try 0R on VDDA.

[ataradov]

This is normal. This just means some internal reset is happening. Read the value of RCC_CSR, it will tell you why this happens.

But do the resistor first.

[VK3DRB]

Can you be more specific, you are saying nReset (pin 7 of the MCU) is going from 3V to 0V without outside intervention? That doesn't really make sense.
Does 3V-MCU change at all when that happens?
Does it happen with the debugger disconnected? (maybe its wired incorrectly)

VDDA should not be tied to Vdd with a 10k resistor. Change that to 0R.

I THINK IT IS FIXED!!!!!!

It was that 10K resistor to VDDA. I only put it in there due to a legacy issue on an earlier design by an engineer who died suddenly last year, so I could not ask him why he put that in.

Chat GPT 4 actually say the voltage on the VDDA is important, and if it has the wrong voltage on it (eg: 10K will drop it), it will cause resets from the SPI! That ChatGPT is remarkable.

A big thank you to Alex and thm_w. If either of you ever visit Melbourne, I will buy you a beer. THANKS!

[ataradov]

Chat GPT 4 actually say the voltage on the VDDA is important, and if it has the wrong voltage on it (eg: 10K will drop it), it will cause resets from the SPI! That ChatGPT is remarkable.

Was SPI mentioned as part of the query?

I don't think this is anything specific to the SPI. It is likely that reset happens due to brownout monitor on the VDDA, which sags with a consumption spike. SPI just happened to be the first thing used that caused that consumption.

[VK3DRB]

I suspect so.

Interestingly, the same issue was on two other boards with a different STM32L151 (48 pin rather than 64 pins as is the case now, with different I/O capabilities). They worked fine until exercising the SPI. Then there was no device found with the programmer. Even shorting out the 10K does not work on those two boards. It does not matter though because I have spare boards. I can only assume the different chip die types were the reason.

[VK3DRB]

Chat GPT 4 actually say the voltage on the VDDA is important, and if it has the wrong voltage on it (eg: 10K will drop it), it will cause resets from the SPI! That ChatGPT is remarkable.

Was SPI mentioned as part of the query?

I don't think this is anything specific to the SPI. It is likely that reset happens due to brownout monitor on the VDDA, which sags with a consumption spike. SPI just happened to be the first thing used that caused that consumption.

I don't know. I didn't write the query. The engineer who subscribed the ChatGPT 4 wrote it.

Chat GPT gave me a trial of 4 a few weeks ago. It was very good, but a little pricey about the cost of two Netflix subscriptions.

[ajb]

Can you be more specific, you are saying nReset (pin 7 of the MCU) is going from 3V to 0V without outside intervention? That doesn't really make sense.
Does 3V-MCU change at all when that happens?
Does it happen with the debugger disconnected? (maybe its wired incorrectly)

VDDA should not be tied to Vdd with a 10k resistor. Change that to 0R.

I THINK IT IS FIXED!!!!!!

It was that 10K resistor to VDDA. I only put it in there due to a legacy issue on an earlier design by an engineer who died suddenly last year, so I could not ask him why he put that in.

Yeah, that resistor would definitely be a problem.  VDDA isn't a reference pin, it's a power supply pin and needs a stable, low impedance supply with decoupling just like all of the other power supply pins.  VDDA would supply the ADC/DAC circuitry, but may power other things, possibly including the IO structures in the adjacent pins (since they include analog functions), which you're using for SPI.  In that case, it's no surprise that toggling those pins to drive the SPI bus would drop the voltage at VDDA and trigger a reset, but as ataradov pointed out it's nothing to do with SPI specifically.  The datasheet or reference manual may or may not describe how power is supplied internally, but will definitely specify how the power supplies should be handled, including how much VDDA can deviate from VDD (usually not very much!).  Most MCU datasheets will include a 'schematic checklist' section showing several examples of how to correctly support the IC.

[thm_w]

I suspect so.

Interestingly, the same issue was on two other boards with a different STM32L151 (48 pin rather than 64 pins as is the case now, with different I/O capabilities). They worked fine until exercising the SPI. Then there was no device found with the programmer. Even shorting out the 10K does not work on those two boards. It does not matter though because I have spare boards. I can only assume the different chip die types were the reason.

Those boards may have been locked out due to the Vdda issue. Either a code lock or an option byte was corrupted.
jlink has a built in option to force attempt to clear the IC. Stlink, I assume its also possible there but might be more effort, first step might be trying to change the programming reset mode to hardware (core).

https://community.st.com/t5/stm32-mcus-products/stm32-locked/td-p/476824

[VK3DRB]

I suspect so.

Interestingly, the same issue was on two other boards with a different STM32L151 (48 pin rather than 64 pins as is the case now, with different I/O capabilities). They worked fine until exercising the SPI. Then there was no device found with the programmer. Even shorting out the 10K does not work on those two boards. It does not matter though because I have spare boards. I can only assume the different chip die types were the reason.

Those boards may have been locked out due to the Vdda issue. Either a code lock or an option byte was corrupted.
jlink has a built in option to force attempt to clear the IC. Stlink, I assume its also possible there but might be more effort, first step might be trying to change the programming reset mode to hardware (core).

https://community.st.com/t5/stm32-mcus-products/stm32-locked/td-p/476824

Thanks, that's a good idea I will give that a go when I get a moment. Maybe tonight. The SPI is working. I can talk to the Lora chip registers quite happily. The CC1120 registers all return 0x0F... debugging that right now.

[wek]

While 10kOhm in series with VDDA may have been the primary cause of reset (nice catch, @thm_w !), the fact that it occurred at the moment of SPI starting to transmit (i.e. which causes no extra current from VDDA) possibly indicates problematic ground arrangement.

This may be OK if this is a purely digital circuit (that's why we have digital, so that we can ignore imperfect real world).

JW

[aliarifat794]

your code with additional debugging and delay to find the problems. Here are some links that can give you some clues:
https://community.st.com/t5/stm32-mcus-products/what-is-the-correct-way-to-recover-from-an-spi-error-or-a/td-p/101173
https://community.st.com/t5/stm32-mcus-products/hal-spi-enable-causes-crash-reset-on-stm32g030j6/td-p/162644
https://www.theengineeringprojects.com/2021/11/stm32-spi-communication.html