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

[TDK]

Why do you think HAL_UART_RxCpltCallback freezes? There's no blocking code in it. Doesn't seem likely to freeze.

I don't see anywhere in your code where you receive data from UART4 and send it out on USART3, even in the code that is commented out. Looks like you are receiving data into "buffer" but you don't do anything with it.

[snak3in]

Theoretically, I should open the uart4 reception in the main board with the command "HAL_UART_Receive_IT(&huart4, &rxByte, 1);" right?
I receive one bit at a time, and when that happens, it should call the function "void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)" and, actually, by doing some tests, I see that the callback gets in for a certain number of bytes and then stops.
It seems like it's receiving a few bytes and slowly. I also checked the electrical signals using an oscilloscope on the processor pins, and indeed, if I send a test string "12345678X" to the uart4 pins, it arrives correctly, but when I take it from uart4 and send it back to uart3, the terminal where I read uart3 shows "12357X," so it's not the complete string.

I modified the program to make it simpler and as I think it should theoretically work, I removed all the parts that I had used as tests.

[Andrew Neil]

---

@snak3in wrote:

I receive one bit at a time, 

---

You receive one byte at a time.

[Guenael Cadier]

Hi @snak3in 

my 2 cents :
- Depending on your code optimization options, it might be safe to declare PacketLength and Packet Ready as volatile, as they could be updated in interrupt context and checled in main().

- Reception will stop (i.e. no more RXNE interrupts will be generated), if an overrun event occurs. When your reception seems "frozen", please check ISR OVR bit in UART registers.
If set, it needs to be cleared so that reception could restart.

Regards

 

[snak3in]

Sorry, can you explain point two better? I also replied to someone else above, and maybe it could be helpful for you to better understand what's going on and help me.
Anyway, you're really kind. I've modified the code and already sent it to the person above if you'd like to see it.

[Karl Yamashita]

You are not checking for HAL status when you call HAL_UART_Receive_IT in your callback. If it does not return HAL_OK, then you'll never get an interrupt. You have to check the status, then try to enable again in main while loop.

 

HAL_StatusTypeDef hal_status = {0};

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
	packetReady = true;
 if(huart == &huart4)
 {
 buffer[idx++] = rxByte;
 if(idx >= 128 || rxByte == 'X') {
 packetReady = true;
 packetLength = idx;
 idx = 0;
 }
 hal_status = HAL_UART_Receive_IT(&huart4, &rxByte, 1);
 }
}

int main(void)
{


 while(1)
 {
 if(hal_status != HAL_OK)
 {
 hal_status = HAL_UART_Receive_IT(&huart4, &rxByte, 1);
 }
 }
}

 

[snak3in]

I managed to solve the problem simply by changing the baudrate value from 115200 to 9600 for the uart channels.
Thanks anyway everyone for the advice!

[Andrew Neil]

That sounds like you have just masked the symptoms, rather than actually solved the underlying problem.

As @Karl Yamashita said, ignoring HAL return codes is never a great idea.

 

---

Orignally, @snak3in wrote:

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

---

Changing the baud rate shouldn't affect that at all.

By slowing the baud rate from 115200 to 9600, your transmissions now take twelve times longer - probably, that's enough to avoid some timing issue (eg, race condition) in your code...

[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.