Problem with UART receiving and transmitting on STM32u535ret6

[snak3in]

I have a custom board with an STM32U535RET6. This chip receives data from another processor using UART4 on pins PA0 and PA1. Once the data is received, it should be sent to another chip using USART3 on pins PC4 and PC5.

If I transmit a fixed string directly, it works correctly. However, if I try to transmit the data received from UART4 (which is a message of about 70 bytes ending with "X"), it does not work.

Additionally, HAL_UART_RxCpltCallback seems to freeze. I added a log inside the callback and I can see it print, but after a few executions, it stops running and no more bytes are received.

I hope someone can help me, I can send more files if needed

[snak3in]

ok, I added those pieces of code that control the status of the HALs, however the transmission of messages with a baud rate of 115200 still does not work well, I tried changing the clock but it still does not work.

[Andrew Neil]

---

@snak3in wrote:

the transmission of messages with a baud rate of 115200 still does not work well,

---

What, exactly, does that mean?

Describe precisely & completely the symptoms you see.

[snak3in]

So, I have this custom board with an STM32U535RET6 that receives messages from a BLE processor on its UART4. Both are set to 115,200 baud rate. I see that only a few bytes are taken from the STM32U535RET6, but if I set the baud rate on both to 9600, everything works perfectly.
Sorry if I can't explain myself well, but I'm still a beginner.

[Andrew Neil]

---

@snak3in wrote:

 I have this custom board .

---

What custom board?

Please post the schematic.

See: How to write your question to maximize your chances to find a solution.

Before adding the complications of a custom board and BLE processor, have you thoroughly tested your serial comms against a PC terminal, or similar ?

This is always a fundamental first step to getting serial comms working; eg, see this.

See also: Tips on Debugging Serial Comms.

---

@snak3in wrote:

 I see that only a few bytes are taken from the STM32U535RET6

---

What do you mean by, "only a few bytes are taken" ?

How do you observe that ?

[snak3in]

It's a custom electronic board I made.
Yes, I tested the serial ports, and they work.
I can tell that only some bytes are being received on the STM32U535RET6's HUART4 because using the HUART3, I can display what I want on a terminal and use it as a log. So I print the received character and notice that only some of the total string is received. For example, if the string I was supposed to receive is "12345678," I see the terminal print the characters "12358."

[TDK]

> I see that only a few bytes are taken from the STM32U535RET6, but if I set the baud rate on both to 9600, everything works perfectly.

> For example, if the string I was supposed to receive is "12345678," I see the terminal print the characters "12358."

Sounds like a clock mismatch between the two. Invalid characters are dropped so you only see those that pass.

Get a logic analyzer and look at the clock rate actually being sent. Use HSE rather than HSI, or tune HSI up/down by 1% increments to get it to work. 114048 instead of 115200, etc.

[Andrew Neil]

---

@snak3in wrote:

Yes, I tested the serial ports, and they work.

---

How, exactly, did you "test" them?

How did you determine that your testing was representative of the BLE unit's actual behaviour?

---

@snak3in wrote:

 if the string I was supposed to receive is "12345678," I see the terminal print the characters "12358."

---

How are you sure that the transmitted string actually was "12345678," ?

Is the receiving UART flagging any errors (eg, framing, noise) ?

If  "12345678," actually was transmitted, and you only received "12358" at 115200, but it works fine at 9600, that again sounds like a timing problem in your code: you code is too slow to keep up at 115200, but the slower speed allows it to keep pace.

I think you need to do more testing off the custom board.

That seems a very complex board for a beginner to be starting on!

[snak3in]

I've already tried changing the clock with the two options you gave me, but I don't think I succeeded. Could you explain better how to do both? Does it make any difference if I make the changes to the initialization from the main.c file or with the graphics on .ioc?

[Andrew Neil]

---

@snak3in wrote:

Does it make any difference if I make the changes to the initialization from the main.c file or with the graphics on .ioc?

---

No.

The C code is just generated from the settings in the ioc.

[snak3in]

ok thanks, now I solved the problem, it was enough to increase M SIS in the clock configuration to 12000 KHz, before I had it at 4000