STM32H755 – End-of-Frame Detection Fails Only with EventFlags, Works with Polling

[Ibrahimsha]

Hello ST Team,

I am using an STM32H755ZIT6 where CM7 handles a high-speed Quad-SPI flash interface with 100Mhz and UART communication with flow control 115200 baud.
The same firmware runs on two hardware revisions:

• Revision V2: Works perfectly

• Revision V3: Same firmware → occasional failure in UART frame processing

The QSPI itself receives data correctly (verified with CRC), but the “end of frame” indication is occasionally not processed.

---

Observed Firmware Behavior

1. Using RTOS Event Flags (original implementation)

In the UART receive callback, when “end of frame” (EOF) is detected, we set an RTOS event flag:

osEventFlagsSet(dataReceiveEvent, DataReceived);

Problem on V3:

• Sometimes the event flag is not triggered

• Even though all received bytes are correct

• CRC validation passes

• The callback executes, but the main task does not wake

This leads to missed packets even though the data is fully received.

---

2. Switching to Polling Loop (temporary workaround)

We replaced the RTOS event flag with a simple polling mechanism inside the processing task:

while(1) 
{ 
  if(osMessageQueueGet(...) == osOK)
  process(); 
  osDelay(10); 
}

With this change:

• V3 hardware works consistently

• No EOF detection failures

• No lost frames

• V2 continues to work as usual

This confirms the raw UART data is always correct — only the timing window of the RTOS wake-up is sensitive.

---

3. Interpretation (What I need ST guidance on)

It appears that:

• The UART ISR + RTOS event-flag + context switching timing is borderline in some conditions

• Minor timing jitter causes occasional missed RTOS event wakeups

• Polling hides this issue because it does not depend on a precise timing window

---

4. Questions for ST

1. Are there known conditions where CMSIS-RTOS2 EventFlags used inside UART RX callbacks can be missed due to timing jitter or interrupt priority interactions?

2. Is there any recommendation on:

   • Minimum ISR execution time

   • Maximum recommended operations inside UART RX callback

   • Priority level requirements for tasks waiting on EventFlags

3. Does ST recommend using:

   • Ring buffer + task polling

   • Direct-to-queue from ISR

   • Stream buffer

   • Event flags
     for continuous, critical UART communication?

4. Any known errata for STM32H7 regarding:

   • EventFlags not waking tasks

   • Interrupt latency

   • Missed wakeups under high-load conditions

---

5. Summary

• Data reception is always correct

• CRC is valid

• Only the RTOS event flag wake-up occasionally fails

• Polling solves the problem

• Need guidance on recommended ISR → task signaling method for STM32H7

Thank you in advance.