TouchGFX auf externem QSPI-Flash – STM32H7B0
- Auftraggeber
- Internes Embedded-Produkt
- Jahr
- 2024
- Kategorie
- Embedded-Systeme
Um den begrenzten internen Flash des STM32H7B0 zu umgehen, wurde die TouchGFX-Anwendung aus externem QSPI-Flash gestartet. Dafür mussten Bootablauf, Speicherabbildung und QSPI-Anbindung auf der ARM-Cortex-M7-Plattform abgestimmt werden.
Individueller Bootloader für Hardwareinitialisierung, Execute-in-Place-Mapping (XIP) und den sauberen Sprung zur Anwendung auf dem externen QSPI-Flash.
Eigener STM32CubeProgrammer External Loader zur direkten Programmierung des QSPI-Flash sowie eine vollständige TouchGFX-Oberfläche zur funktionalen und qualitativen Prüfung der Ausführung.
Die Herausforderung
Die TouchGFX-Anwendung passte nicht mehr in den internen Flash des STM32H7B0. Die Anwendung sollte deshalb aus externem QSPI-Flash ausgeführt werden; zugleich musste der externe Speicher in den Programmierablauf mit STM32CubeProgrammer eingebunden werden.
Unser Vorgehen
Ein individueller Bootloader wurde geschrieben, der die Hardware initialisiert, den Speicher für Execute-in-Place (XIP) mappt und sauber zur externen Anwendung springt. Anschließend wurde ein eigener STM32CubeProgrammer-External-Loader entwickelt, um das QSPI-Flash direkt aus der IDE zu programmieren; eine vollständige TouchGFX-Oberfläche mit schaltflächenbasierter Interaktion validierte die Systemleistung.
Das Ergebnis
Die Lösung nutzt den externen QSPI-Flash für Anwendung und Ressourcen, bindet dessen Programmierung in den Entwicklungsablauf ein und demonstriert die interaktive Ausführung einer TouchGFX-Oberfläche aus externem Speicher.
Ergebnisse
- Nutzung des externen QSPI-Flash trotz begrenztem internem Programmspeicher
- Programmierung des externen QSPI-Flash direkt aus der IDE
- Flüssige Ausführung einer vollständigen TouchGFX-Oberfläche aus externem Speicher
Haben Sie ein ähnliches Projekt?
Sprechen Sie mit dem Engineering-Team von NELSco über die Anforderungen Ihres Projekts.