cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 UART only working with debugger

sireevenkat1
Senior

Hi,

I am working with STM32g491re custom board. With UART communication our STM32 and other MCU communicating.
After flashing the firmware with debugger both boards are communicating properly but once power off & on If other board sends the data stm32 is not responding at all. Again if I flash the firmware by connecting the debugger again both boards are communicating.
UART communication I implemented interrupt communication.
Can anyone suggest what will be the reason both are communicating only with debugger.

Thanks
 

12 REPLIES 12

issue some how solved after giving some delay in the uart receiver callback of stm32.

Does debugger provides some delay to the programming??


Timing is critical with embedded systems. A debugger session usually adds a breakpoint at the beginning of your main. Then it waits until you click run or hit F8. And your board is already powered on when flashing firmware at the start of your debug session, so there is additional time before running compared to power cycle without debugger. In addition you may have some variables in your live viewer which might force the debugger to periodically pause the MCU to read some variables. All these things affect timing.

Have you attached a logic analyser? I would look at the power, TX, RX and reset pins of your Modem and then compare the working scenario to the non-working scenario. It usually needs some time after reset before it can respond (read the datasheet of your modem for proper power-up, initialization and power down routine). Also if you are sending data before it is powered on you are phantom feeding the modem through its RX pin. If that is happening you can solve this by initializing your MCU TX pin after the Modem powered on, or add a series resistor between your MCU TX and Modem RX. Or use an open drain configuration (pullup to the switched power and open drain output setting for MCU TX).

Kudo posts if you have the same problem and kudo replies if the solution works.
Click "Accept as Solution" if a reply solved your problem. If no solution was posted please answer with your own.
shunyata
Associate

Hey, 

hope you have got your solution by now but if not. Kindly try to add delays in between the AT commands that require writing and clearing of buffers. and ensure that all buffers are getting cleared before you receive next. This happens when buffers are not cleared and and you try to receive the next response this response gets mixed with the previous response and it does not get compared with the actual response you are expecting. So clearing the buffer and providing the regular delays to give time to buffer to get clear is important.


@shunyata wrote:

try to add delays in between the AT commands that require writing and clearing of buffers. 


No, don't rely upon arbitrary delays for AT commands!

After issuing an AT command, wait until all responses have been received & processed.

Only after all the responses have been received,  processed, and observed should you send the next command.

 

https://www.avrfreaks.net/s/topic/a5C3l000000UYp7EAG/t147655?comment=P-1409865

 

#BlindDelays