STM32... How can SPI cause a reset? Serious bug here. - Page 1
Forum section: electronics / general

author: VK3DRB
author_rank: Super Contributor
timestamp: May 30, 2024, 12:18:00 am
content: 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 CC1120data = 0x30; // Reset command for CC1120if (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 */}

author: ataradov
author_rank: Super Contributor
timestamp: May 30, 2024, 12:45:02 am
content: 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().

author: thm_w
author_rank: Super Contributor
timestamp: May 30, 2024, 12:54:50 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: May 30, 2024, 01:00:03 am
content: Quote from: thm_w on May 30, 2024, 12:54:50 amReset 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.

author: VK3DRB
author_rank: Super Contributor
timestamp: May 30, 2024, 01:13:04 am
content: Quote from: ataradov on May 30, 2024, 12:45:02 amI 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--;}

author: ataradov
author_rank: Super Contributor
timestamp: May 30, 2024, 01:15:40 am
content: Check the reset reason. There is no obvious reason why this would cause the reset.

author: VK3DRB
author_rank: Super Contributor
timestamp: May 30, 2024, 01:21:26 am
content: Quote from: thm_w on May 30, 2024, 12:54:50 amHere 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.

author: ataradov
author_rank: Super Contributor
timestamp: May 30, 2024, 01:25:05 am
content: 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.

author: VK3DRB
author_rank: Super Contributor
timestamp: May 30, 2024, 01:54:31 am
content: Quote from: thm_w on May 30, 2024, 12:54:50 amI 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!

author: ataradov
author_rank: Super Contributor
timestamp: May 30, 2024, 02:03:50 am
content: Quote from: VK3DRB on May 30, 2024, 01:54:31 amWas 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.

author: VK3DRB
author_rank: Super Contributor
timestamp: May 30, 2024, 03:06:09 am
content: 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.

author: VK3DRB
author_rank: Super Contributor
timestamp: May 30, 2024, 03:09:46 am
content: Quote from: ataradov on May 30, 2024, 02:03:50 amI 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.

author: ajb
author_rank: Super Contributor
timestamp: May 30, 2024, 02:55:28 pm
content: Quote from: VK3DRB on May 30, 2024, 01:54:31 amYeah, 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.

author: thm_w
author_rank: Super Contributor
timestamp: May 30, 2024, 09:19:24 pm
content: Quote from: VK3DRB on May 30, 2024, 03:06:09 amThose 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

author: VK3DRB
author_rank: Super Contributor
timestamp: May 30, 2024, 11:55:18 pm
content: Quote from: thm_w on May 30, 2024, 09:19:24 pmThanks, 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.

author: wek
author_rank: Frequent Contributor
timestamp: June 03, 2024, 07:20:21 am
content: 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

author: aliarifat794
author_rank: Regular Contributor
timestamp: June 07, 2024, 12:50:00 pm
content: 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/101173https://community.st.com/t5/stm32-mcus-products/hal-spi-enable-causes-crash-reset-on-stm32g030j6/td-p/162644https://www.theengineeringprojects.com/2021/11/stm32-spi-communication.html

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: June 12, 2024, 07:46:56 pm
content: Just curious, did you ever check RCC_CSR when the issue occurred? I'm wondering what its value was.

author: glenenglish
author_rank: Frequent Contributor
timestamp: June 13, 2024, 09:11:38 am
content: "Chat GPT says "LOL, sir you really must not believe anything it says.it has no concept of true or false