STM32H Dual-Core: FreeRTOS auf beiden Kernen und Kommunikation über Shared Memory

Die STM32H7®-Dual-Core-Familie, zum Beispiel der H745 oder H755, trägt einen Cortex-M7® und einen Cortex-M4 auf einem Chip. Beide Kerne laufen unabhängig. Diese Betriebsart heisst AMP, asymmetrisches Multiprocessing.

Die Aufgabenteilung ist klar: Der M7 übernimmt die Rechenlast bei hoher Taktrate. Der M4 übernimmt die deterministische Peripherie-Arbeit. Für die Zusammenarbeit brauchen die Kerne geteilten Speicher und einen Weckmechanismus.

Dieser Artikel zeigt beides. Zuerst je ein FreeRTOS™ pro Kern. Dann einen gerichteten Kanal über einen FreeRTOS Message Buffer im geteilten Speicher, geweckt über die Hardware-Semaphore-Einheit.

Warum kein dedizierter DSP

Ein Cortex-M7 bringt eine doppelt genaue FPU und den DSP-Befehlssatz mit. Die typische digitale Signalkonditionierung eines Sensors läuft damit in vielen Fällen ohne separaten DSP-Baustein. Der M4 übernimmt parallel die deterministische Peripherie- und Zeitarbeit.

Zur typischen Signalkonditionierung gehören:

• FIR- und IIR-Filter. Tief-, Hoch-, Band- und Kerbfilter gegen Netzbrumm und Ausserbandrauschen, Median-Filter gegen Ausreisser, Hochpass gegen Offset-Drift.
• FFT und Spektralanalyse. Mit Fensterung (Hann, Hamming), Peak-Suche und Energie pro Band. Für eine einzelne Zielfrequenz genügt ein Goertzel-Filter.
• Korrelation und Matched-Filter. Laufzeitmessung, Mustererkennung, Kreuzkorrelation zweier Signale.
• Synchrondetektion und Lock-in. Phasenempfindliche Demodulation und I/Q-Mischung, um ein schwaches Signal bei bekannter Frequenz aus dem Rauschen zu holen.
• Dezimation und Ratenwandlung. Oversampling mit Dezimation, CIC-Filter, Noise-Shaping für zusätzliche effektive Bits.
• Hüllkurve und Effektivwert. Envelope, RMS, Spitzenwert, gleitende und kohärente Mittelung.
• CORDIC. atan2, Betrag und Phase, Winkel für Resolver und Encoder.
• Adaptive Filter. LMS oder RLS für Stör- und Echokompensation.
• Kalman und Sensorfusion. Zustandsschätzung und Fusion mehrerer Sensoren.
• Kalibrierung und Linearisierung. Offset, Verstärkung, Kennlinie, Temperaturkompensation, Brücken- und Kaltstellenkompensation.
• Merkmalsextraktion. RMS-Trend, Crest-Faktor, Kurtosis für Condition-Monitoring.
• Ereignis- und Schwellenerkennung. Nulldurchgang, Flanken, Hysterese, Entprellung.
• Regelung. PID-Schleife, wenn der Sensor Teil einer geschlossenen Schleife ist.

Für AI- und Edge-Computing mit hohem Durchsatz, also neuronale Inferenz, sind Controller dieser Klasse nicht ausgelegt. Solche Aufgaben brauchen einen dedizierten NPU- oder Edge-AI-Baustein.

Ein dedizierter DSP lohnt sich erst, wenn Durchsatz oder Latenz die Reserven des M7 übersteigen. Darunter spart die Dual-Core-Lösung einen Baustein, eine zweite Toolchain und die Kopplung zwischen zwei Chips.

Für harte Echtzeit im I/O gibt es einen weiteren Weg ohne DSP: Hardware-Parallelität statt interrupt-getriebener Software. Diesen Ansatz beschreibt unser Artikel Parallel statt unterbrochen: XMOS xCORE im Vergleich zur klassischen MCU.

Zwei Kerne, zwei RTOS-Instanzen

Jeder Kern bekommt sein eigenes FreeRTOS-Image mit eigenem Heap und eigenem Scheduler-Tick. Es gibt keinen gemeinsamen Scheduler. Ein Task auf dem M7 sieht die Tasks auf dem M4 nicht.

Der Boot läuft gestaffelt. Der M7 startet zuerst, konfiguriert Takt und Speicher und gibt danach den M4 frei. Damit steht die geteilte Umgebung, bevor der zweite Kern seinen Puffer benutzt.

Der H7 teilt den Speicher in Domänen. Das SRAM4 in der Domäne D3 ist von beiden Kernen und vom DMA erreichbar. Es eignet sich als Ablage für den geteilten Puffer.

Shared Memory richtig platzieren

Die Cache-Kohärenz ist die zentrale Falle. Der M7 hat einen L1-Datencache, der M4 hat keinen. Schreibt der M7 in den geteilten Speicher, bleibt der Wert zunächst im Cache. Der M4 liest dann den alten Wert aus dem RAM.

Es gibt zwei saubere Wege. Der erste markiert den geteilten Bereich per MPU als non-cacheable. Der zweite pflegt den Cache von Hand, mit Clean nach dem Schreiben und Invalidate vor dem Lesen.

Die erste Variante ist robuster. Eine MPU-Region für den Puffer als non-cacheable und shareable eliminiert die manuellen Cache-Operationen und ihre Fehlerquellen. Den Puffer legt der Linker per eigener Section in das SRAM4, auf beiden Images an dieselbe Adresse.

Wecken über die Hardware-Semaphore

Geteilter Speicher allein reicht nicht. Der Empfänger muss erfahren, dass Daten bereitliegen. Aktives Pollen kostet CPU-Zeit und erhöht die Latenz.

Der H7 hat eine Hardware-Semaphore-Einheit (HSEM) mit Interrupt. Kern A löst nach dem Schreiben eine Semaphore aus. Das erzeugt einen Interrupt auf Kern B. So wird der Empfänger-Task erst geweckt, wenn wirklich Daten anliegen.

Aus dem Reference Manual RM0399 kurz zusammengefasst, welche Register man tatsächlich anfasst:

• HSEM_R0 … HSEM_R31 (Semaphore Register): je ein 32-Bit-Register pro Semaphore. Lock durch Schreiben von LOCK=1 | COREID | PROCID in einem einzigen Zugriff, Release durch Schreiben von LOCK=0 mit derselben COREID/PROCID (Wert wird sonst verworfen).
• HSEM_RLR0 … HSEM_RLR31 (Read-Lock Register): 2-step-Lock durch reines Lesen; setzt das Lock-Bit automatisch, wenn die Semaphore frei war.
• HSEM_IER1 / HSEM_IER2 (Interrupt Enable): pro CPU ein 32-Bit-Register, ein Bit je Semaphore. Bit setzen aktiviert den HSEM-Interrupt am Ziel-Kern, wenn diese Semaphore freigegeben wird.
• HSEM_ISR1 / HSEM_ISR2 (Interrupt Status): Read-only, zeigt welche Semaphore den Interrupt am jeweiligen Kern ausgelöst hat.
• HSEM_MISR1 / HSEM_MISR2 (Masked Interrupt Status): ISR & IER, das ist die für die ISR relevante Sicht.
• HSEM_ICR1 / HSEM_ICR2 (Interrupt Clear): Bit schreiben löscht das Pending-Bit am jeweiligen Kern.
• HSEM_KEYR und HSEM_CR: Key-basierter Sammelrelease aller Semaphoren eines Kerns (für Reset-Szenarien).

Konkreter Pfad in unserem Code: nach dem Senden schreibt Kern A HSEM_R<id> = 0x0000_0000 (Release), was das Pending-Bit im HSEM_ISR2 von Kern B setzt. Der Interrupt HSEM2_IRQn feuert am Ziel-Kern, die ISR quittiert per Schreiben in HSEM_ICR2 und ruft xMessageBufferSendCompletedFromISR.

FreeRTOS Message Buffer über die Kerngrenze

Ein FreeRTOS Message Buffer ist ein Single-Writer/Single-Reader-Konstrukt. Genau das passt zu einem gerichteten Kanal von Kern A zu Kern B. Für beide Richtungen legt man zwei Buffer an.

Der Buffer, also Steuerstruktur und Datenbereich, liegt im geteilten, non-cacheable SRAM4. FreeRTOS bietet zwei Hooks für die Signalisierung: sbSEND_COMPLETED und sbRECEIVE_COMPLETED.

Man überschreibt diese Hooks. Ein Send auf Kern A löst über die Hardware-Semaphore einen Interrupt auf Kern B aus. Die ISR auf Kern B ruft xMessageBufferSendCompletedFromISR auf und weckt damit den wartenden Empfänger-Task. Der Kanal ist so blockierend und ereignisgesteuert, ohne Polling und ohne globalen Lock.

/* Geteiltes, non-cacheable SRAM4, gleiche Adresse in beiden Images */
extern MessageBufferHandle_t xCoreAtoB;   /* von CM7 erzeugt */

/* Hook: nach einem Send die Gegenseite per HSEM wecken */
#define sbSEND_COMPLETED(pxBuf)   vHsemNotify(HSEM_ID_A2B)

/* Läuft auf CM4, wenn CM7 gesendet hat */
void HSEM1_IRQHandler(void)
{
    BaseType_t xHigher = pdFALSE;
    vHsemClear(HSEM_ID_A2B);
    xMessageBufferSendCompletedFromISR(xCoreAtoB, &xHigher);
    portYIELD_FROM_ISR(xHigher);
}

/* Sender-Task auf CM7 */
xMessageBufferSend(xCoreAtoB, &frame, sizeof frame, portMAX_DELAY);

/* Empfänger-Task auf CM4 */
len = xMessageBufferReceive(xCoreAtoB, &frame, sizeof frame, portMAX_DELAY);

Die Namen vHsemNotify, vHsemClear und HSEM_ID_A2B sind Platzhalter für die Semaphore-Primitive des Projekts. Für die Gegenrichtung legt man einen zweiten Buffer und eine zweite Semaphore-ID an.

Ablauf

1. Den Puffer per Linker-Section in das SRAM4 legen, mit gleicher Adresse in beiden Images.
2. Eine MPU-Region für das SRAM4 als non-cacheable konfigurieren, auf beiden Kernen.
3. Den Buffer auf genau einem Kern erzeugen, mit xMessageBufferCreateStatic. Der andere Kern wartet, bis der Buffer bereit ist.
4. Den Semaphore-Interrupt auf beiden Kernen freischalten, je eine ID pro Richtung.
5. sbSEND_COMPLETED so definieren, dass es die Semaphore der Gegenrichtung auslöst.
6. In der ISR xMessageBufferSendCompletedFromISR mit dem Handle des lokalen Buffers aufrufen.

Fallen

• Cache. Der Puffer nicht als non-cacheable konfiguriert. Der Empfänger liest alte Daten. Das ist der häufigste Fehler.
• Adress-Mismatch. Beide Images sehen den Buffer nicht an derselben Adresse. Per gemeinsamem Linker-Symbol fixieren.
• Struktur-Layout. Beide Images übersetzen die Buffer-Struktur nicht identisch. Gleiche FreeRTOS-Version und gleiche Konfiguration auf beiden Kernen verwenden.
• Boot-Reihenfolge. Der zweite Kern greift auf den Buffer zu, bevor der erste ihn erzeugt hat. Der zweite Kern muss auf ein Bereit-Flag warten.
• Interrupt-Freigabe. Der Semaphore-Interrupt ist auf einem Kern nicht im NVIC freigegeben. Das Wecksignal kommt nie an, der Empfänger blockiert dauerhaft.

Lehre

Der Dual-Core-H7 trennt Rechnen und Echtzeit-Peripherie sauber auf zwei Kerne. Die Kopplung braucht keine fremde Middleware. Ein FreeRTOS Message Buffer im geteilten, non-cacheable SRAM4, geweckt über die Hardware-Semaphore, reicht für einen robusten Kanal.

Der grösste Stolperstein ist nicht die Logik des Kanals, sondern die Cache-Kohärenz. Wer den geteilten Bereich von Anfang an non-cacheable hält, umgeht die häufigste Fehlerquelle im Dual-Core-Design.

Der H7 spielt seine Stärken dort aus, wo Rechenleistung führt: FFT-lastige Signalverarbeitung, hoher Kommunikationsdurchsatz, Grafik-HMI, mehrere komplexe Protokolle parallel. Für dieses Profil ist die Dual-Core-Aufteilung mit einem RTOS pro Kern die saubere Antwort.

Schlüsselwörter: STM32H7 Dual-Core, Cortex-M7, Cortex-M4, FreeRTOS Message Buffer, Shared Memory, SRAM4 non-cacheable, Hardware-Semaphore HSEM, AMP asymmetrisches Multiprocessing, Cache-Kohärenz, dsPIC33CH, ASIL-B ASIL-C, Embedded Consulting Schweiz, swissEmbedded Firmware Entwicklung