cancel
Showing results for 
Search instead for 
Did you mean: 

MCU shutting down during SPI communicaiton

Stoufer
Associate III

I have a simple demo board with a STM32L451VET6, a SPI LCD and four switches. The board will send the first byte over SPI perfectly, then either during or right after sending the second byte - it appears the MCU shuts down - as the CS line drifts down to 0v and single stepping in the code it just stops stepping - no errors - no faults.

This is a minimal program with just two lines added to the auto-generated code.

Any Ideas ?

Stoufer_0-1694538436110.png

 

1 ACCEPTED SOLUTION

Accepted Solutions
Stoufer
Associate III

Resolved!  BOOT0 was left unconnected. Set it as input and tied to GND and everything is workin ggreat!

Thanks!

View solution in original post

11 REPLIES 11
Stoufer
Associate III

Stoufer_0-1694538619195.png

two bytes sent .. then ... it dies

 

Issamos
Lead II

Hello @Stoufer 

I suggest you to  change the CS pin. If the problem persist,try using another SPI interface.

Best regards.

II

 

TDK
Guru

Likely to be a hardware issue. Probe the NRST line, probably gets pulled low and holds the chip in reset. Look at power rails and ensure sufficient current capacity. Ensure power to chip is valid.

If you can show the schematic, please do.

If you feel a post has answered your question, please click "Accept as Solution".
Pavel A.
Evangelist III

and single stepping in the code it just stops stepping - no errors - no faults.

The behavior when the target dies depends on the debugger. Which debugger do you use? (CubeIDE gdb, CubeIDE OpenOCD, Keil, IAR... ?)

I am using a ST-Link

Stoufer
Associate III

Stoufer_0-1694617665871.png

Here is the schematic - and attached also.

I believe you are right about it being HW. I started a new project with just one GPIO pin toggling. It works when single stepping but if I let it run it runs for about a second and stops. I did find I had a couple 3.3V pins not connected and AGND was not connected to GND - fixed those thinking that was the trouble... but its still stopping. And I have tested on two boards - same bad behavior....

Stoufer
Associate III

NRST is the problem! See trace below - yellow is GPIO bit toggling - it runs the same number of cycles every time I run it ( 51). The light Blue trace is NRST... now WHY is NRST going low ??? Is it something with my ST-Link ?? 

Stoufer_0-1694619481540.png

Here is the only code I added :

  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */
  HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_SET);
  HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_RESET);
  HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_SET);
  HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_RESET);
 
    /* USER CODE BEGIN 3 */
  }

 

more clues... If I place a breakpoint on the first GPIO set statement above and run it ... It will run and break until I have see 24 sets of 2 toggles ( 48 )... then when I run it again - it locks up. No toggles and NRST goes low :

Stoufer_1-1694620454724.png

so it appears to be related to the number of instructions executed ? Almost like a WDT - but I dont have WDT setup unless there is something on by default... i have a 8Mhz crystal on board but have it configured for internal MSI RC @4000kHz.

Any suggestions ?

THANKS!!

TDK
Guru

Schematic looks fine.

> I did find I had a couple 3.3V pins not connected and AGND was not connected to GND - fixed those thinking that was the trouble

That was the trouble. Doesn't mean there aren't more issues. Check all connections to VDD and VSS. Show high resolution photos of the relevant solder joints.

Again, monitor 3.3V rail to see if it drops.

If you feel a post has answered your question, please click "Accept as Solution".