STM32F103: Sometimes USART stops working

[Aniket_Karanje]

Hi, 

We are using STM32F103 in our project. Established IPC communication over USART. We have almost finished our development. We kept our setup running for long, sometimes we found that IPC-USART communication getting stuck, IPC does not work until we reset it by external pin. Is there any issue with USART of this chip?

Your help would be appreciated.

Thank you.

[mƎALLEm]

Hello,

What do you mean by "IPC communication" ? 

and by this:  "IPC does not work until we reset it by external pin" ?

[Aniket_Karanje]

IPC - Inter Processor Communication using USART1

we have one BLE chip which communicates with the STM32F103 chip through IPC communication. That means these chips exchanging data over USART. At ST site USART1 is used, with 115200 Baud rate, DMA is used.

Here BLE chip can reset ST chip by pulling low it's NRST.

After IPC-USART1 communication broken from ST site, BLE chip resets ST chip after waiting for 30 seconds.

At ST site we used Window watchdog, which I tested, and it is working fine.

[Andrew Neil]

---

@Aniket_Karanje wrote:

IPC - Inter Processor Communication

---

So "IPC communication" is a tautology, then - isn't it?

---

@Aniket_Karanje wrote:

IPC-USART1 communication broken from ST site, 

---

How do you know it's broken from the ST side ?

How often does this "stuck" situation occur?

Is there anything that seems to make it better or worse?

What debugging/investigation have you done to find what's going on?

[Karl Yamashita]

---

@Aniket_Karanje wrote:

After IPC-USART1 communication broken from ST site, BLE chip resets ST chip after waiting for 30 seconds.

---

This is vague. Write a better description of what is actually not working. What kind of data/messages are going on between the two devices? How do you know if your receive routine was written correctly but instead went off into the weeds? Show some code.

[Tesla DeLorean]

Check for and clear any pending error status on the STM32F103 UART, say noise, framing, parity errors, etc. as these would preclude further reception until cleared/acknowledged.

[Aniket_Karanje]

@Andrew Neil 

"IPC communication" is a tautology, then - isn't it? -> correct.

How do you know it's broken from the ST side ?

- > Because BLE side other stuffs were working fine.

How often does this "stuck" situation occur?

- > It is random.

Is there anything that seems to make it better or worse? What debugging/investigation have you done to find what's going on?

- > I tried by continuously sending data from BLE chip to ST chip. My ST chip stuck there, and then Watchdog reset it.

[Aniket_Karanje]

ST site USART stops working after some days, if setup ran continuously.

[Aniket_Karanje]

Yes

[Andrew Neil]

---

@Aniket_Karanje wrote:

How do you know it's broken from the ST side ?

- > Because BLE side other stuffs were working fine.

---

That doesn't make much sense.

Maybe "other stuffs" could continue working on the BLE side when its UART has stopped?

---

@Aniket_Karanje wrote:

- > I tried by continuously sending data from BLE chip to ST chip. My ST chip stuck there, and then Watchdog reset it.

---

So investigate that further!

• spy on the UART lines to see what's actually happening between the 2 chips
• instrument your code to give insight into what's happening within the ST chip
• As @Tesla DeLorean said, be sure to catch & handle any UART errors. Provide external visibility to see when these happen.

@Aniket_Karanje wrote:

ST site USART stops working 

---

How do you know it's the ST UART which stops working?

How do you know it's not the BLE UART which stops working (properly)?

The UARTs (hardware) may be fine, but the software gets confused ...