STM32L4 UART2 Management

[dtarrago]

Posted on September 22, 2017 at 11:09

Good morning,

In the application I'm developing, I'm controlling a transceiver by Microchip via UART2 port. I have several prototypes already working but I have some others (same hardware) that have some problems with this UART communication. When a board works fine, it works always fine. The problem lies on the boards that are not working fine and I have found the reason: for these boards, I have noticed that when asking for information to the transceiver, I get the answer with a 0x00 at the beginning => as in my code I use String functions, this 0x00 at the beginning generates the problems I have.

I do not know if the origin of this problem is in the transceiver or MCU side, so:

- Could you tell me a reason of why I receive 0x00 for some boards and it is not received for others? (Please, note that I have some boards but we are always talking about the same hardware)

- Now I have solved this issue by rejecting 0x00 characters, but it is not the most elegant way to proceed....

Best regards.

#stm32l4 #uart

[dtarrago]

Posted on September 27, 2017 at 08:43

Furthermore, what I have seen using this transceiver an also using another device with another USART: RXNE flag is activated when the HAL_UART_TxCpltCallback is called. In this case, this should not happen as when 'HAL_UART_Transmit_IT' function is called, reception is not allowed...

[dtarrago]

Posted on September 27, 2017 at 09:39

RE flag is also enabled before UART transmission and is should not...

[AvaTar]

Posted on September 27, 2017 at 10:05

RE flag is also enabled before UART transmission and is should not...

Why not ?

The receiver and the transmitter sections hardly depend on each other, and can work concurrently.

Both (RX and TX) interrupts are handled by the same interrupt vector, but can again be treated independent of each other.

Not sure what Cube/Hal does about it, I never use/used it.

If you have spurious receptions (RXNE interrupts), check the UART error flags.

Perhaps you have noise on the lines, that triggers those 0x00 bytes.

In difference to 'normal' receptions, these error flag do not reset automatically, or with reading the register.

You need to reset them explicitly, or you never receive another character.

[AvaTar]

Posted on September 27, 2017 at 12:27

I always receive what I have to receive but together with a non-expected character at the beginning.

Have checked with a scope, i.e. is this a real received character ?

always I have Overrun Error after sending a command....

The callback routines do run in the interrupt context, don't they ?

As said, Cuba/HAL is not for me ...

I suspect you spend too much time in an interrupt routine, be it a differnt interrupt, the send callback, or even the receive callback itself.

If a character is received while another unread character is still in RX, the overrun flag is set, and reception stops - until you explicitly reset the OR flag.

Do as few as possible in the interrupt (including callbacks) itself, rather use flags or other mechanisms to delegate it to your synchronous main code.

[dtarrago]

Posted on September 27, 2017 at 10:44

I always receive what I have to receive but together with a non-expected character at the beginning.

In the way I'm working, I send a command via UART and then I have to read something. Every time I send a command, the status of the ISR register is as depicted in the attached picture (it has been catched being stopped at 'HAL_UART_TxCpltCallback' function): always I have Overrun Error after sending a command....

[Tesla DeLorean]

Posted on September 27, 2017 at 14:33

The other thing is that if you send dozens of characters the receiver can expect to see a similar number of characters in the same time frame. So you can't just ignore the RX when doing a TX, these thing need to occur in parallel, and if you sit in a call-back blocking execution other interrupts may be ignored.