cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 TIM CC IRQ and USART RXNE IRQ

ommo-junyu
Associate II

Hi everyone,

I’m working on an STM32C0 setup where TIM1 CH1 (Pin A) and UART RX (Pin B) are physically shorted together, and I’ve encountered some unexpected interrupt behavior. Specifically, the UART RXNE interrupt always triggers before the TIM1 Capture Compare (CC) interrupt when the UART receives a byte 0x00.

Setup Details:

TIM1 Configuration:

  • TIM1 CH1 is configured for Input Capture on the rising edge.
  • IRQ priority is set to 0 (highest priority).
  • Rising edge detection, no prescaler, no filter.

UART Configuration:

  • UART RX is enabled with the RXNE IRQ to handle incoming data.
  • IRQ priority is set to 1.

Goal:

The goal is to establish precise timing for sensor data communication:

  1. The UART master sends data at a known timestamp (master clock).
  2. The STM32 UART slave:
    • Uses TIM1 Input Capture to record the timestamp of the rising edge (TIM1 capture value).
    • Handles the UART RXNE IRQ to read the incoming data.
    • Compares the TIM1 capture timestamp with the current TIM1_CNT value to calculate the time difference and sends it back to the UART master.

Issue:

When the UART master sends a byte 0x00, the UART RXNE IRQ consistently triggers before the TIM1 Capture Compare IRQ, even though TIM1 has a higher IRQ priority.

I debugged this using breakpoints on both IRQ functions, and RXNE always executes first.

My Understanding:

I expected the TIM1 CC IRQ to trigger first since:

  1. TIM1 has a higher IRQ priority.
  2. The UART RXNE IRQ might require additional processing time for sampling or data reception.

However, the observed behavior is the opposite: RXNE consistently triggers ahead of TIM1 CC.

Questions:

  1. Does this behavior make sense? Could the UART RXNE IRQ be triggering early, possibly during the start bit or oversampling phase?
  2. Is there something wrong with my setup that could cause this order of interrupts?

Any insights or suggestions to help me understand this behavior or resolve it would be greatly appreciated. Thanks in advance!

2 REPLIES 2

> when the UART receives a byte 0x00

Is that byte correctly terminated by stopbit, i.e. has the correct duration for startbit+8 data bits?

Are there any status bits set by UART?

JW

gbm
Lead III

The behavior makes sense. UART RX may be triggered at 9/16 of stop bit period. It should make no difference to you, as the timer correctly records the timestamp. You may service the UART RX in timer interrupt, having RXNE interrut disabled while waiting for the sync frame. Also, you could detect high-to low transition of start bit instead. So: not really a problem; few solutions available.

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice