STM32F411VET UART2 questions

[SDall.11]

Hi, I've some questions about STM32F411VET and UART2.

Is UART2 in this MCU native or emulated?

I ask this, because despite I use an interrupt to receive data through calling to "void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)" callback, I had to lower speed to 38400 to avoid data loss.

Also I have to wait 400ms between sending one packet and another, otherwise the data vanishes into thin air.

Is normal this?

Thanks.

Regards.

[Tesla DeLorean]

USART2 is hardware, look at diagrams in data sheet.

It is important not to block in callback/interrupt context. They should exit promptly, and defer processing that will take more than a byte time, or is unpredictable, to a secondary task.

>>Also I have to wait 400ms between sending one packet and another, otherwise the data vanishes into thin air. Is normal this?

No, sounds like an implementation / buffering issue, the HW is more than capable of handling this without data loss.

[SDall.11]

Hi, thanks for your answer.

The callback is very light:

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
  Uart2Buffer[Index++] = ch;
  if(Index >= 256) Index = 0;
  HAL_UART_Receive_IT(huart, (uint8_t *)&ch, 1);
}

I'm modifyng a firmware wrote from another person.

Is possible that this person have used interrupts or anything else that can cause problems to UART2?

For the interrupts it seems to me to haven't seen problems but...

Thanks.

[Tesla DeLorean]

Data loss can occur due to a lot of factors.

The handler here is relatively lite, but the method doesn't look safe with potent race conditions with the consuming end.

In a safer implementation the index variable would only be modified by the handler, and complete buffers dispatched to the processing thread.

[SDall.11]

Hi, and thanks for answer.

To try to understand the problem, I made a little software that manage only usart2.

In this case, the usart2 works very fine at 115200 and don't loss a single byte.

Then, I've compared the code of this test software with code of software I'm working on and they are identical.

So I checked if there is another part of code that can conflict with USART2 and I have not found anything.

I searched instruction that disable interrupts, but there is one not used in my case.

The loop time is less then one milliseconds then I think that this not a problem.

What else could I check?

I finished ideas :(

Thanks.

[SDall.11]

Solved, I found a function with problems.

Thanks for support.

[Amel NASRI]

Hi @SDall.1​ ,

Glad to know that your problem was resolved. It would be interesting if you can share more details about your findings, as it may help other Community members.

-Amel

[SDall.11 · Accepted solution]

Hi Amel, 

the problem was in a function that update lcd display.

It was composed of two annidated "for".

First "for" was x8 and second x128.

This probably occupied MCU too long, blocking the rest of functions and interrupts.

[Amel NASRI]

OK, thanks @SDall.1​ for sharing this. I'll select your reply as best answer.

-Amel