USART Rx interrupt NOT Work

[SoHaeng.Lee]

Posted on October 17, 2017 at 18:03

I tested three devices all day long today.

All devices are connected to the USART, but the incoming interrupt does not work at all.

A program that connects the Lo Ra modules, GPS modules, and wifi modules to USART 1 and outputs the data sent to USART 2.

However, the Rx Interrupt does not work at all.

Attach the project file.

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Tesla DeLorean]

Posted on October 17, 2017 at 20:17

Does receive work in polled mode? Can you confirm signal performance on a scope?

Not sure I'd be calling a blocking function like HAL_UART_Transmit() with a 1 second timeout in a callback.

[SoHaeng.Lee]

Posted on October 18, 2017 at 02:49

Thank you very much.

I tested your advice, but it still doesn't work.

I have 4 devices.(stm32f103c8t6, uncle-f446re, stm32f4-disco, stm32f3-disco)

The result was all the same.

If you have a similar device, try testing it.

Setting the delay time of the HAL_UART_Receive_IT function to 1000ms causes the program to stop.

The polling mode has not yet been tested.

today, I'll try.

thanks, civil.

attached project is for Nucleo-F446re.

[Tesla DeLorean]

Posted on October 18, 2017 at 03:01

I'm not an advocate for the HAL library, but I can tell you from experience the USARTs on these boards function properly. The USART1 PA9/PA10 is not connected suitably on the STM32F4-DISCO to work properly. On that board I use uBlox GPS connected on USART2 PD5/PD6

To debug USART issues you need to check signals with a scope, and review if RXNE asserts, or other error states are signalled and need clearing.

It is critical that code in callbacks should not block, because otherwise data loss is bound to occur on one or more interfaces.

I would avoid parking the Peripheral View of the debugger on the USART

[Tesla DeLorean]

Posted on October 18, 2017 at 03:31

I use Keil, attached is a quick blind port forwarding USART1 to USART2 (VCP) at 9600 baud. Use the ST LINK Utilities to burn the firmware, review interaction via Terminal application opening the STM COM port at 9600 8N1

________________ Attachments : NUCLEO64-F446RE-USART1_2_FORWARD_000.hex.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxpd&d=%2Fa%2F0X0000000b6f%2FxViyZyJ1sSQOp0iW9H1nmGwt26EybgcUKPUgm5HtLHU&asPdf=false

[John Craven]

Posted on October 18, 2017 at 06:15

You have blocking transmits in both uart1 and uart2 interrupt handlers. 

Have you done a simpler project to test if you can send and rec (no interrupts) to USB via uart2?

are your solder bridges on the Nucleo correct for pa2/pa3 to the stlink?

[SoHaeng.Lee]

Posted on October 18, 2017 at 05:20

maybe, I'm afraid it's a HAL library bug. 

[Tesla DeLorean]

Posted on October 18, 2017 at 05:54

What you're doing isn't overly complicated, and I would see it impacting as many boards, there's perhaps something more fundamentally wrong here. I've provided a couple of things to try to establish some ground truth.

[John Craven]

Posted on October 18, 2017 at 06:03

Yep, he should go right back to your first line and see if anything is wiggling on the scope or logic analyzer!

[SoHaeng.Lee]

Posted on October 18, 2017 at 06:23

Four boards and three devices were tested. We also checked the scope of data from the device to the board using the scope.

However, the board does not recognize the Rx interrupts.

If I test dozens dozens of times, the result is the same.

After connecting the device and the usb2serial device to a test, i also verified that the data was transferred from the device.

So I think it's a bug in a library.