STM32 UART only working with debugger

[sireevenkat1]

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
 

[Andrew Neil]

---

@sireevenkat1 wrote:

both boards are communicating properly

---

Tell more about these boards, how they communicate, and how they are connected.

Schematics and some good, clear photos would help.

Could it be that you're missing a ground connection, and the debugger provides that?

 

---

@sireevenkat1 wrote:

If other board sends the data stm32 is not responding at all.

---

So what tests have you done to see what's happening?

eg,

• How do you know it's not responding at all ?
• Is the STM32 actually running at all? maybe it's stuck in a Hard Fault or something ... ?
• Provide LEDs to confirm operation ?
• Trace output to another UART ?
• etc, etc, ...

 

EDIT:

Another possibility when stuff "only works with debugger" is that your board is not properly resetting the microcontroller ...

[sireevenkat1]

Hi @Andrew Neil ,

One is STM32G491RE and other is N58.Both are communicating through STM32.Data format defined for both boards.
Based on the data received from N58 ,Stm32 responds to N58.\

Schematics I can't able to share it.

• How do you know it's not responding at all ?
  • From web server i can bale to check when stm32 not responds I get failure indication

    • Is the STM32 actually running at all? maybe it's stuck in a Hard Fault or something ... ?

     

    ---

    I kept led for indication they are responding. If hard fault comes how can I solve it.?
    
    Thanks

•  

---

[Andrew Neil]

---

@sireevenkat1 wrote:

Hi @Andrew Neil ,

One is STM32G491RE and other is N58.

---

---

what is "N85" ?

 

---

@sireevenkat1 wrote:

Schematics I can't able to share it.

---

---

If not full board schematics, at least a schematic of how the boards are connected together.

You've also mentioned a "web server" - so how does that fit in?

Again, some good, clear photos would help.

Remember that we know nothing about your system other than what you describe here - if you can't find the problem(s) when it's your system, and you know what it does and how it all connects and you have it right there in front of you - how do you expect people with no information and no access to do any better?

Do you not have colleagues / classmates / supervisors to help you?

 

---

@sireevenkat1 wrote:

• • From web server i can bale to check when stm32 not responds I get failure indication

---

---

Again, what "web server" ?

Can you add better diagnostics via this "web server" ?

Does that actually tell you that the STM32 doesn't respond at all - or just that it doesn't respond as expected/required?

 

---

@sireevenkat1 wrote:

• • . If hard fault comes how can I solve it.?

---

---

First thing to determine is whether a Hard Fault is occurring at all.

 

In case you missed the late edit to my previous post:

Another possibility when stuff "only works with debugger" is that your board is not properly resetting the microcontroller ...

[Tesla DeLorean]

>>>One is STM32G491RE and other is N58.

>>what is "N85" ?

I stared at my goats, and they double-dyslexic'd this to probably this..

https://www.neoway.com/products/wireless-communication/823.html

[Douglas MILLER]

Hello Sireesha

This post has been escalated to the ST Online Support Team for additional assistance. We'll contact you directly.

[Andrew Neil]

Another thing you haven't said is what debugger you're using.

Does it supply power to the board?

[sireevenkat1]

Hi @Andrew Neil ,@ Tesla DeLorean,
1.
N58: Neoway N58 is an LTE Cat. 1 module optimized specially for M2M and IoT applications
https://www.euromobile.ru/upload/iblock/8e5/Neoway_N58_Datasheet_V1.1.pdf

2. About schematic:
I know I am sorry for the inconvenience  I will check with my team what things can I share in the forum.

3.

Do the boards share a common ground?

Do the Output signals on one board go to the Input on the other?

---

STM32 supplies 5v supply and ground to the N58 board.

Another thing you haven't said is what debugger you're using.

Does it supply power to the board?

 

---

Debugger I am using is Segger Jlink debugger.I only connected SWD lines and ground to PC.VCC line I didn't connected to the STM32 and debugger.

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

Does debugger provides some delay to the programming??


Thanks

[Andrew Neil]

---

@sireevenkat1 wrote:

  I will check with my team what things can I share in the forum.

---

If you've got a team, it would be far better to get them involved in helping you!

People in your own team on the same project with access to the actual hardware and knowledge of the project will be far better placed to help you than complete strangers far away with no access to or knowledge of your system.

 

---

@sireevenkat1 wrote:

Does debugger provides some delay to the programming??

---

That depends on what you're doing with it.

 

---

@sireevenkat1 wrote:

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

---

That sounds like a flaw in your comms handling; eg, your code is not ready at the point that the modem sends stuff.

You need to debug that - otherwise it's likely to come back and bite you later ...

Meanwhile, please mark the solution to this thread.

[shunyata]

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.

[Andrew Neil]

---

@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