SERIOUS Problem with clock configuration STM32L051K6U6TR

[EBdhaifi]

Hi community,

I have a serious problem with this microcontroller STM32L051K6U6TR.

I have created a code using STM32CubeIDE and based on STM32CubMX wizard creator, however, the clock is set up to match the microcontroller & its peripherals (USART, I2C, ..) clock requirements as shown this photo :

 

The generated code is compiled and flashed to the microcontroller without any error. I just tried this code :

 

thr problem is that the microcontroller gets crached. After debugging the code, I released that this issue is coming from HAL_Delay, because if I try the code without it, the proble is gone. Finally, I released that any call of a function or setting that uses the Clock of the CPU, the craching of the code occurs. I played a lot with the clock configuration in CubeMX to solve it but the same problem is still there, because I'm still thinking that maybe the clock setting generated by the CuBeMX is not supported physically by the microcontroller.

Did anyone face a simular issue ? Any suggestion might be a great help.

[waclawek.jan]

How do you know the code is crashing? What are exactly the symptoms?

Is this a known-good hardware like Nucleo or Disco?

JW

[TDK]

> Finally, I released that any call of a function or setting that uses the Clock of the CPU, the craching of the code occurs.

Literally every instruction uses the CPU clock. Not just function calls. If it was a serious clock issue, your code would not make it to the main loop.

Debug the code, hit pause, examine why it's "crashed" specifically and address/debug as needed.

[EBdhaifi]

Hello,

the code is not literary "crached" but lets say enters into infinite loop inside this function :

while((HAL_GetTick() - tickstart) < wait)
 {
 }

So my understanding is that the microcontroller cannot get a tick in millisecond from the main clock, that's why a tried a lot of clock configuration.

Unfortunately this microcontroller is not used in any dev-board.

[EBdhaifi]

Hello,

the code is not literary "crached" but lets say enters into infinite loop inside this function :

while((HAL_GetTick() - tickstart) < wait)
 {
 }

So my understanding is that the microcontroller cannot get a tick in millisecond from the main clock, that's why a tried a lot of clock configuration.

[TDK]

Your code is stuck within HAL_Delay, but that's where you code should be 99.99% of the time because your main loop doesn't do anything useful. What exactly is the issue here?

Why are you claiming it is crashed as opposed to operating normally?

[EBdhaifi]

The code should not be stuck within HAL-Delay, it must execute the for loop again after 10ms :

  int b=0;
     /* Infinite loop */
     /* USER CODE BEGIN WHILE */
     while (1)
     {
   		 for (int j=0;j<5;j++) {
   			 b++;
   		 }
   		 HAL_Delay(10);
  }
  /* USER CODE END 3 */

But in my case, it keeps running infinitely ones entering into the HAL_Delay for the first time and it's stuck there.

[TDK]

You don’t use your variable anywhere. The compiler is free to optimize it out. Perhaps blink an LED instead.
Monitor uwTick to verify ticks are happening. The HAL_Delay logic is very simple. Not going to be a bug in there, but open it up and look.

[EBdhaifi]

Here's 2 examples :

1- Do something without the delay : plot "system running" to serial port

code :

  int b=0;
  uint8_t serialBuff[60];
     /* Infinite loop */
     /* USER CODE BEGIN WHILE */
     while (1)
     {
   		 for (int j=0;j<5;j++) {
   			 b++;
   		 }
 
   		 strcpy((char*)serialBuff,"System running\r\n\n");
   		 HAL_UART_Transmit(&huart2, serialBuff, strlen((char*)serialBuff), 1000);
   		 //HAL_Delay(1000);
  }

result on serial monitor : the uC works fine and plots "System running" fastly

2- Do something with the delay : plot "system running" to serial port

code :

  int b=0;
  uint8_t serialBuff[60];
     /* Infinite loop */
     /* USER CODE BEGIN WHILE */
     while (1)
     {
   		 for (int j=0;j<5;j++) {
   			 b++;
   		 }
 
   		 strcpy((char*)serialBuff,"System running\r\n\n");
   		 HAL_UART_Transmit(&huart2, serialBuff, strlen((char*)serialBuff), 1000);
   		 HAL_Delay(1000);
  }

result : the code plots "system running" just one time before executing HAL_Delay, and then is stuck there :

 

[EBdhaifi]

SOLVED !!

The issue was that the BOOT0 wasn't pulled down properly 😉