Warum und wie man den Mikrocontroller-Programmspeicher mit SPI-XiP-Flash erweitert

Angesichts der zunehmenden Komplexität von Mikrocontroller-Anwendungen setzen Entwickler immer häufiger Flash-Programmspeicher für die Anwendungsfirmware ein. Dies gilt insbesondere für IoT-Endpunkte (Internet der Dinge), die gerade anfangen, relativ komplexe Randknotenprozesse zu übernehmen. Manchmal können Anwendungen allerdings ein solches Ausmaß annehmen, dass externer Programmspeicher erforderlich ist, und an dieser Stelle müssen sich die Entwickler zwischen parallelem und seriellem Flash entscheiden.

Das Hinzufügen eines externen parallelen Flash-Speicherchips bindet jedoch I/O-Leitungen, erhöht die Komplexität und verbraucht zusätzlichen Platz auf der Platine. In diesem Artikel soll es darum gehen, wie sich der Flash-Programmspeicher von Mikrocontrollern erweitern lässt, indem ein externer serieller Flash-Speicherchip von Adesto Technologies hinzugefügt wird, der eine SPI-XiP-Schnittstelle (eXecute in Place) unterstützt. Er beschreibt auch, wie der XiP-Flash in den Speicherplatz eines Mikrocontrollers von Microchip Technology eingebunden wird, sodass die Code-Ausführung für die Firmware nahezu transparent wird.

Gründe für externe Speichererweiterung

Wo möglich, sollten Entwickler bei der Anwendungsentwicklung damit beginnen, einen Mikrocontroller auszuwählen, der bereits eine Roadmap von Pin-kompatiblen Bausteinen mit mehr Arbeitsspeicher bietet. Falls dann im Laufe der Entwicklung die Anwendungsfirmware über den Flash-Speicher hinaus anwächst, der auf dem Zielbaustein verfügbar ist, kann der Entwickler einfach zu einem Pin-kompatiblen Baustein mit mehr Flash-Speicher wechseln. Dies ermöglicht die Erweiterung des Anwendungsspeichers, ohne dass dazu die Platine für einen anderen Mikrocontroller komplett neu konzipiert werden muss.

Allerdings kann die Anwendung möglicherweise mehr Programmspeicher erfordern, als auf dem Chip einer Pin-kompatiblen Mikrocontroller-Familie verfügbar ist, was dann den Einsatz von externem Flash-Speicher notwendig macht. Das tritt immer häufiger auf und kann aus mehreren Gründen passieren, darunter:

• Der Systemumfang kann sich im Lauf der Entwicklung über das ursprüngliche Konzept hinaus erweitern. Ursache hierfür können in letzter Minute vorgenommene Änderungen an der Anwendung, Erweiterung um neue Funktionen oder nicht präzise Vorhersage des Speicherbedarfs der Anwendung sein. Hier sind die Optionen entweder ein Upgrade durch einen Pin-kompatiblen Mikrocontroller, der mehr Flash-Speicher bietet, oder das Hinzufügen von zusätzlichem externen Flash-Programmspeicher, was jedoch das Projekt verzögern kann, wenn die Entwicklung bereits weit fortgeschritten ist.
• Spätere Firmware-Upgrades im Praxisbetrieb können mehr Flash-Programmspeicher erfordern, als auf dem Mikrocontroller verfügbar ist, der bereits in der Systemplatine verbaut ist. In dieser Situation sind die Optionen begrenzt: Entweder werden die in der Praxis eingesetzten Systeme durch solche mit mehr Flash-Programmspeicher ersetzt oder das Upgrade wird abgebrochen.
• Die Weiterentwicklung der Systemproduktfamilie erfordert möglicherweise ein neues Produkt, das mehr Flash-Programmspeicher benötigt, als bereits für die Pin-kompatible Mikrocontroller-Familie verfügbar ist. Die Optionen bestehen darin, das System mit einer neuen Mikrocontrollerfamilie neu zu entwerfen oder externen Flash-Programmspeicher hinzuzufügen.

Ganz offensichtlich kommt es darauf an, dass Entwickler die Bedürfnisse der gegenwärtigen und zukünftigen Systeme hinsichtlich dieser Speichererweiterung antizipieren und bereits mit einplanen. Falls die Möglichkeit besteht, dass das Projekt später externen Flash-Programmspeicher benötigt, sollte der Entwickler eine Stelle für die zukünftige Erweiterung auf der Platine vorsehen. Auch wenn die Bestückung des Boards mit einem Flash-Speicherchip nicht erforderlich scheint, ist es besser, auf Sicherheit zu gehen und den Platz bereits angelegt zu haben.

Die traditionelle Variante der Erweiterung von Flash-Programmspeicher war der Einsatz einer parallelen Flash-Schnittstelle mit Adress- und Datenleitungen. Doch selbst die effizienteste Nutzung eines parallelen Flash-Speichers, die nicht zu Lasten der Geschwindigkeit geht, braucht 16 Bits für die Adresse, 16 Bits für die Daten und mindestens vier Steuersignale. Dies erfordert 36 oder mehr Mikrocontroller-Pins.

Neben einer ineffizienten Nutzung der Ressourcen eines Mikrocontrollers begrenzt dies auch die Auswahl der Mikrocontroller auf Bausteine mit externem Bus, was wiederum die Pin-Anzahl des Mikrocontrollers erhöht. Ein externer paralleler Bus verbraucht auch erheblichen Platz auf der Platine, während die hohe Geschwindigkeit von Adress- und Datenbus die Wahrscheinlichkeit von elektromagnetischen Interferenzen (EMI) erhöht.

Ausführung von SPI-XiP-Code

Eine effektivere Option ist die Verwendung eines externen Flash-Programmspeicherbausteins, der eine SPI-XiP-Schnittstelle unterstützt. Eine SPI-XiP-Schnittstelle kommt mit nur sechs Pins für die Anbindung an den Host-Mikrocontroller aus. Im Gegensatz zu einer herkömmlichen SPI-Schnittstelle erfolgt der Zugriff auf den Arbeitsspeicher des externen Flash-Speicherbausteins nicht direkt über einen SPI-Firmware-Treiber, sondern der Arbeitsspeicher wird vielmehr direkt in den Programmspeicher des Mikrocontrollers eingebunden.

Ein gutes Beispiel eines seriellen Flash-Speicherbausteins, der für die Anbindung über eine SPI-XiP-Schnittstelle konzipiert wurde, ist der AT25SL321-UUE-T von Adesto Technologies (Abbildung 1). Es handelt sich dabei um einen 32 Megabit (Mbit) Flash-Speicher, der Single-, Dual- und Quad-SPI-Betriebsarten unterstützt. Er arbeitet mit einem SPI-Taktgeber mit 104 Megahertz (MHz), der im Dual-SPI-Modus eine Taktrate von 266 MHz und im Quad-SPI-Modus eine Taktrate von 532 MHz ermöglicht.

Abbildung 1: Der AT25SL321 von Adesto ist ein 32-Mbit-Flash-Speicher, der Single-, Dual- und Quad-SPI-Betriebsarten unterstützt. Er bietet 32 Mbit Flash-Speicher in einem SOIC-, DFN8- oder TSSOP8-Gehäuse mit 8 Pins. (Bildquelle: Adesto Technologies)

Neben den 32 Mbit an Flash verfügt der Baustein über Statusregister zu seiner Konfigurierung. Über das Auslesen der Statusregister kann die Firmware feststellen, ob in dem Baustein gerade ein Schreib- oder Löschvorgang durchgeführt wird. Durch Schreiben in die Statusregister können ganze Blöcke des Flash-Speichers schreibgeschützt werden.

Der AT25SL321 von Adesto bietet zudem 4 Kilobit (Kbit) an einmal programmierbarem (OTP) Speicher, der zum Speichern von Sicherheitsinformationen wie einer eindeutigen Seriennummer verwendet werden kann. Er ist in einem SOIC-, DFN8- oder TSSOP8-Gehäuse mit 8 Pins untergebracht.

Wie alle seriellen Speicherbausteine, die SPI-XiP unterstützen, wird auch der AT25SL321 von Adesto mit einem Befehlssatz konfiguriert, der speziell für die Adesto-Bausteine ausgelegt ist. Der Befehlssatz umfasst 38 Befehle, die vom Host-Mikrocontroller zur Steuerung des seriellen Flash verwendet werden. Ein SPI-XiP-Peripheriegerät auf einem Host-Mikrocontroller umfasst eine programmierbare Zustandsmaschine, die beim Hochfahren des Microcontrollers mit dem Befehlssatz des seriellen Ziel-Flash initialisiert wird. Nach der Initialisierung ist der Betrieb der SPI-Peripheriekomponente für die Firmware transparent, die Code in der dem Arbeitsspeicher zugeordneten SPI-XiP-Region ausführt.

Wenn die Firmware des Host-Mikrocontrollers beispielsweise Daten aus der dem Arbeitsspeicher zugeordneten Region liest, sendet die SPI-XiP-Region, die mit dem Adesto-Befehlssatz konfiguriert wurde, einen Read-Data-Befehlscode, gefolgt von einer 24 Bit breiten Byte-Adresse für den seriellen Adesto-Speicher. Der serielle Adesto-Speicher sendet dann den Speicherinhalt Byte für Byte an den Host-Mikrocontroller. Für die Firmware sieht das wie ein ganz normaler Lesevorgang aus dem Speicher aus.

Neben den SPI-Taktgeber-, Daten- und Chip-Select-Pins bietet der AT25SL321 zwei weitere Pins zur Verbesserung der In-System-Funktionalität. WP\ ist ein Aktiv-Low-Schreibschutz-Pin, der das Schreiben in das Statusregister verhindert, wodurch ganze Blöcke von Code schreibgeschützt sind. Der Mikrocontroller kann diesen Pin verwenden, um Aufgaben mit niedriger Priorität daran zu hindern, unberechtigte Änderungen vorzunehmen. HOLD\ wird verwendet, um eine laufende Datenübertragung zu pausieren. Dies kann nützlich sein, wenn der Mikrocontroller ein Interrupt-Signal mit hoher Priorität empfängt, während eine Datenübertragung zum Speicher läuft, die pausiert werden muss, bis der Interrupt erledigt ist.

Der 32-Mbit-Flash-Baustein AT25SL321 von Adesto unterstützt vier Betriebsarten:

• Standard-SPI-Betrieb: Der Zugriff auf den Flash-Speicher erfolgt wie bei einem Standard-SPI-Baustein mit SPI-Taktgeber (SCLK), Aktiv-Low-Chip-Select (CS\), seriellen Eingangs- (SI) und seriellen Ausgangsdaten (SO). Die Standard-SPI-Bus-Modi 0 und 3 werden unterstützt.
• Dual-SPI-Betrieb: Diese Betriebsart bietet die doppelte Datenrate des Standard-SPI-Betriebs, indem SI und SO als bidirektionale Daten-Pins verwendet werden, ausgewiesen als IO0 und IO1.
• Quad-SPI-Betrieb: Diese Betriebsart bietet die vierfache Datenrate des Standard-SPI-Betriebs. Neben IO0 und IO1 werden auch WP\ und HOLD\ als bidirektionale Daten-Pins verwendet: IO2 und IO3. Im Quad-SPI-Betrieb sind die WP\- und HOLD\-Funktionen nicht verfügbar.
• QPI-Betrieb: Diese Betriebsart wird nur für den SPI-XiP-Betrieb genutzt. Während die Standard-, Dual- und Quad-SPI-Betriebsarten alle das Senden von Befehlen an den SPI-Speicher lediglich unter Nutzung des IO0-Pins unterstützen, unterstützt der QPI-Betrieb das Senden von Befehlen über die vier IO[0:3]-Pins, was die SPI-XiP Leistung deutlich verbessert.

Wenn selbst die 32 Mbit des AT25SL321 von Adesto nicht ausreichen, bietet derselbe Hersteller auch den AT25QL641-UUE-T mit 64 Mbit. Die beiden Bausteine sind Pin-kompatibel, sodass der AT25QL641 als Drop-in-Ersatz genutzt werden kann. Außer dass er einen größeren Speicher bietet, besteht der einzige Unterschied zwischen den beiden Bausteinen darin, dass der AT25QL641 so ausgelegt ist, dass er beim Hochfahren standardmäßig im QPI-Betrieb arbeitet. Dies verringert die Setup-Zeit des Bausteins in Hochleistungssystemen. Beide Bausteine verbrauchen für einen Speicherlesezyklus nur 5 Milliampere (mA). Beide Adesto-Speicherbausteine werden über eine einzige 1,7- bis 2,0-Volt-Schiene versorgt und können an jeden spannungskompatiblen Mikrocontroller angebunden werden, der über eine SPI-XiP-Schnittstelle verfügt.

Für den Einsatz als Host-Mikrocontroller bietet Microchip Technology SPI-XiP-Schnittstellen bei seiner ATSAMD51-Serie, zu der auch der auf einem 120 MHz Arm®-Cortex®-M4F-basierende Mikrocontroller ATSAMD51J20A-UUT zählt. Dieser Baustein bietet 1 MB an Flash und 256 Kilobyte (KB) an RAM. Er verfügt über eine vollständige Palette an Peripheriegeräten, einschließlich Analog/Digital-Wandler (ADC), Digital/Analog-Wandler (DAC), USB-Port und I²S. An Sicherheitsfunktionen bietet er eine Peripheriekomponente zur Verschlüsselung öffentlicher Schlüssel sowie über einen Generator für echte Zufallszahlen (True Random Number Generator, TRNG).

Abbildung 2: Der ATSAMD51J20A von Microchip bietet einen vollständigen Satz von Peripheriekomponenten, darunter eine serielle SPI-XiP-Schnittstelle, ADC, DAC sowie Unterstützung für die Datenverschlüsselung. (Bildquelle: Microchip Technology)

Zur Verbindung mit externem Flash-Speicher können Entwickler das QSPI-Peripheriegerät des ATSAMD51J20A verwenden, das SPI-XiP unterstützt. Dies ermöglicht die direkte Ausführung von Code aus dem Adesto-Flash-Speicher. Der ATSAMD51J20A bindet den Adesto-Flash in den AHB-Programmspeicher (Advanced High Performance Bus) des Arm-Kerns ein. Zum Schutz der Daten im seriellen Flash unterstützt die SIP-XiP-Schnittstelle des ATSAMD51J20A die transparente Verschlüsselung von Daten, die in den externen SPI-Speicher geschrieben werden, und die Entschlüsselung von Daten, die aus dem externen SPI-Speicher gelesen werden. Dies kann dazu beitragen, unbefugtes Kopieren von Firmware und Systempiraterie zu verhindern.

Abbildung 3: Der 32-Bit-Mikrocontroller ATSAMD51J20A von Microchip bietet ein QSPI-Peripheriegerät, das einen seriellen SPI-XiP-Port unterstützt. Damit kann er problemlos über lediglich sechs Pins mit dem seriellen Flash AT25SL321 verbunden werden. (Bildquelle: DigiKey)

Verwendung des ATSAMD51J20A von Microchip mit einem seriellen Flash-Speicherbaustein von Adesto

Das SPI-XiP-Peripheriegerät des ATSAMD51J20A von Microchip bietet drei Register zum Senden von Befehlen an einen externen seriellen XiP-Flash. Da die seriellen Flash-XiP-Speicherbausteine unterschiedlicher Hersteller mit verschiedenen Befehlscodes arbeiten, müssen diese Register vom Entwickler wie folgt für den jeweils verwendeten Speicheranbieter konfiguriert werden:

1. Das Befehlscode-Register enthält den Befehl, der für den Zugriff auf den seriellen Flash-Speicher verwendet wird. Bei einem Adesto-Flash-Speicherbaustein, der im Quad-SPI-Modus arbeitet, enthält dieses Register einen Fast-Read-Quad-Output-Befehl 0x6B, wenn die Firmware Code aus dem der XiP-Region zugeordneten Speicher ausführt. Dieses Register muss in den entsprechenden Befehlscode geändert werden, wenn eine Schreib-, Lösch- oder Statusregister-Operation durchgeführt wird.
2. Das Befehlsadress-Register enthält die Flash-Speicheradresse, auf die in dem externen seriellen Flash zugegriffen wird. Wenn die SPI-XiP-Schnittstelle des ATSAMD51J20A von Microchip für den seriellen Speichermodus konfiguriert ist, wird diese Adresse automatisch durch das SPI-XiP-Peripheriegerät in die Adresse geändert, die durch die Firmware in dem zugeordneten AHB Speicherplatzbereich 0x0400 0000 bis 0x0500 0000 verwendet wird.
3. Das Befehls-Frame-Register konfiguriert die SPI-XiP-Schnittstelle für das konkrete Befehls-Frame-Format des jeweils verwendeten externen Speicherbausteins. Hierzu zählen die Auswahl der Adressenlänge von 24 oder 32 Bit, die Aktivierung von Double Data Rate (DDR), die mögliche Unterstützung des kontinuierlichen Lesemodus und die Opcode-Länge.

Der Rest der SPI-XiP-Schnittstelle lässt sich mit den Microchip-SPI-Treibern problemlos konfigurieren.

Solange die Anwendungsfirmware auf dem Mikrocontroller Code aus der dem SPI-XiP-Speicher zugeordneten Region ausführt, ist keine Neukonfiguration des SPI-XiP-Peripheriegeräts auf dem Mikrocontroller erforderlich. Der Adesto-Flash-Speicher unterstützt mit dem Befehlscode 0x03 auch einen Lesemodus über lediglich den SI-Pin. Wenn nur der Dual-SPI-Modus verwendet wird, lautet der Befehlscode 0x3B. Diese Codes werden durch die Anwendungsfirmware in das Befehlscode-Register geschrieben.

Es hat sich in der Praxis bewährt, alle Caches im Zusammenhang mit dem Speicher zu löschen, der dem Adressenraum zugeordnet ist, wenn das Befehlscode-Register geändert wird. Beim Lesen aus den oder Schreiben in die Statusregister des seriellen Flash-Speichers sollte der Cache gelöscht sein und dann deaktiviert werden. Genauso sollte beim Schreiben in den Flash in den dem Speicher zugeordneten Regionen vorgegangen werden. Der Cache sollte wieder aktiviert werden, sobald die Speicherleseoperationen wieder aufgenommen werden.

Aufgrund der dabei auftretenden hohen Geschwindigkeiten bei der Datenübertragung sollte der serielle Flash auf der Platine möglichst nahe zum SPI-XiP-Port des Mikrocontrollers angeordnet werden. Wenn das nicht möglich ist, sollte keine Leiterbahn länger als 120 Millimeter (mm) sein. Das Taktsignal sollte in einer Entfernung von mindestens der dreifachen Breite der Leiterbahnen auf der Platine angeordnet sein, um Interferenzen zu vermeiden. Zur Vermeidung von Versatz sollten die bidirektionalen Datensignale IO[0:3] alle innerhalb von 10 mm zueinander angeordnet sein.

Fazit

Externe serielle Flash-Speicherbausteine können eine schnelle Ausführung von Firmware-Code ermöglichen – ohne die Komplexität und den übermäßigen Platzbedarf von parallelen Flash-Chips. Dies ermöglicht eine einfache Erweiterung des Programmcodes im Laufe der Zeit sowie Updates im Praxisbetrieb ohne Neugestaltung der Systemplatine.