Skip to main content
Visitor II
December 4, 2024
Question

STM32 TIM CC IRQ and USART RXNE IRQ

  • December 4, 2024
  • 3 replies
  • 960 views

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!

    This topic has been closed for replies.

    3 replies

    Super User
    December 4, 2024

    > 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

    Graduate
    December 4, 2024

    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.

    Super User
    December 4, 2024

    > UART RX may be triggered at 9/16 of stop bit period

    Stopbit is 1 so that's already beyond the 0-1 transition which should trigger the TIM capture. Provided that the byte is correctly timed, that is. That's why my question above. 

    JW