Skip to main content
Associate II
August 14, 2025
Solved

Why does the behavior of the while loop I wrote differ from the one generated by STM32CubeMX?

  • August 14, 2025
  • 4 replies
  • 435 views

Hello everyone.

Why does the behavior of the while loop I wrote differ from the one generated by STM32CubeMX? Since the code generated by STM32CubeMX is highly abstracted, is it possible that even the same while loop behaves differently due to internal processing? Where can I learn about such rules? I'm a beginner, so I would really appreciate any guidance. If anyone knows, I would be grateful for your help.

 

Here are the details of the issue.

 

1. When code is written inside the while loop generated by STM32CubeIDE

Code:

Shion_0-1755130651074.png

Result: It doesn't work correctly. It seems that something inside the while loop isn't functioning properly.

Shion_1-1755130821918.png

2. When code is written inside the while loop wrote by myself.

Code:

Shion_2-1755130908489.png

 

Result: It works correctly

Shion_3-1755130945747.png

 

 

 

 

 

Best answer by TDK

Probably due to the unconditional while loop that it gets stuck in. It never makes it to the other code.

TDK_0-1755132855670.png

 

4 replies

TDK
TDKBest answer
Super User
August 14, 2025

Probably due to the unconditional while loop that it gets stuck in. It never makes it to the other code.

TDK_0-1755132855670.png

 

"If you feel a post has answered your question, please click ""Accept as Solution""."
ShionAuthor
Associate II
August 14, 2025

Sorry, your comment is correct. I had mistakenly written the wrong code and result. For some reason, when I place the code inside the while loop generated by STM32CubeMX, TeraTerm becomes unresponsive. However, when I use my own custom while loop, this issue does not occur.

 

When code is written inside the while loop generated by STM32CubeMX

Code:

Shion_2-1755139527281.png

 

Result: It doesn't work correctly. 

 

Shion_0-1755139019236.png

 

Karl Yamashita
Principal
August 14, 2025

Looks like AT commands so the device you're talking to is responding before you call HAL_UART_Receive

You need to enable UART interrupts and use HAL_UART_Receive_IT or enable DMA and use HAL_UART_Receive_DMA 

If a reply has proven helpful, click on Accept as Solution so that it'll show at top of the post.CAN Jammer an open source CAN bus hacking toolCANableV3 Open Source
ShionAuthor
Associate II
August 14, 2025

I apologize. I've found the cause of the issue. It turns out that inserting a break statement into the while loop generated by STM32CubeMX was not appropriate. I'm sorry for troubling you with scuh a basic mistake. Thank you very much for your support.

Karl Yamashita
Principal
August 14, 2025

Well breaking out of the while loop indicates you timed out on receive due to the other device already replied before you called HAL_UART_Receive. You still need to use HAL_UART_Receive_IT

If a reply has proven helpful, click on Accept as Solution so that it'll show at top of the post.CAN Jammer an open source CAN bus hacking toolCANableV3 Open Source