Serieller Anschluss für MSP430-Mikrocontroller

Die größeren MSP430-Controller enthalten zwei asynchron-serielle Schnittstellen (UARTs) sowie (unabhängig davon) einen seriellen Urlader. Unglücklicherweise unterscheiden sich die Anschlusspins für den Urlader und der normalen seriellen Schnittstelle. Deshalb ist das Design eines gescheiten seriellen Anschlusses schwierig und fehlerlastig.

Siehe auch SLAU319 und SLAU265, wie Texas Instruments den Anschluss für den Urlader vorschlägt. Deren Adapter-Schaltpläne sind dabei so ausgelegt, dass man keine Hilfsspannung benötigt, d.h. der MSP430 wird clever von der seriellen Schnittstelle gespeist. Das hier folgende Konzept verwendet einen MAX3232 für hohe Datenraten und erfordert damit eine Fremdspeisung.

Nebenbei vergisst man leicht den Pull-Up-Widerstand für den RESET-Anschluss. Dieser ist nämlich – zumindest im MSP430F1610 – nicht eingebaut.

Schaltung⚓

Der folgende Schaltplan zeigt die Interface-Gestaltung mit folgenden Eigenschaften:

Anschluss mit 9-poligem Verlängerungskabel (kein Nullmodemkabel oder ähnliche Sonderformen) an den PC — X1 ist eine Buchse
Problemloser Betrieb und direkte Anschlussfähigkeit von USB-Seriell-Wandlern
Betrieb des eingebauten Urladers ohne Adapterkabel (d.h. das Füllen mit Firmware erfordert kein spezielles Kabel und keine Brücken)
Betrieb der vorhandenen seriellen Schnittstelle mit beliebiger Baudrate (der MAX3232 ist schnell genug)
Rückführung der Modemstatus-Signale von DTR für automatisches Hardware-Handshake (die Einstellung des Kommunikationsprogramms ist daher unkritisch, sofern man 9-polige Verlängerungskabel benutzt)
Möglichkeit des Einsatzes von „Hardware-Handshake“ in Software mittels RTS und CTS
Unterstützung des Seriellen PnP-Protokolls (dazu wird RTS benötigt) für automatische Hardware-Erkennung

Die Nachteile dieser Lösung mit MAX3232 sollen nicht verschwiegen werden:

Die Gesamtstromaufnahme ist deutlich höher als sonst bei MSP430-typischen Anwendungen
Sechs verstreute Anschlusspins werden okkupiert

Die Verwendung eines MAX3232 (anstelle MAX232) ermöglicht den Betrieb des Pegelkonverters an 3 V. Damit erspart man sich zusätzliche Bauteile zur 5V↔3V-Pegelkonvertierung.

Schaltplan (Vektorgrafik) für maximal-generischen MSP430-Anschluss. Siehe folgende Anmerkungen

Bitte beachte das typspezifische Datenblatt, ob P1.1 und P2.2 die richtigen Portpins für den eingebauten seriellen Urlader sind!

Außerdem verlangen einige MSP430 (typischerweise solche mit gemeinsam genutzten JTAG-Pins) invertierte TCK-Polarität. In diesem Fall heißt der Anschluss TEST, und dieser wird ohne den Widerstand R3 direkt mit RTS verbunden.

Funktionsbeschreibung⚓

Der Urlader erfordert Verbindungen zu TCK, RST, P1.1 und P2.2. Während die seriellen Datenströme TxD und RxD invertiert zugeführt werden müssen (was der MAX3232 erledigt), müssen RTS und DTR nicht-invertiert angeschlossen werden, so dass ein Serienwiderstand gemeinsam mit den eingebauten Gateschutzdioden die Pegelkonvertierung für die beiden Steuerleitungen übernimmt. Der Anschluss RST wird durch den Widerstand R1 hochgezogen, so dass ohne Kabel-Anschluss der Mikrocontroller laufen kann.

Ein direkter galvanischer Anschluss von DTR nach RST erwies sich als sehr unpraktisch, weil so der Mikrocontroller bei Kabel-Anschluss permanent deaktiviert wurde, bis ein Terminal-Programm für das betreffende serielle Port gestartet wurde. Deshalb wurde – als Erweiterung zu den Vorschlägen von Texas Instruments – C1 eingefügt, so dass es nur kurze RESET-Impulse geben kann:

Beim Anschluss eines seriellen Kabels an eine noch ungeöffnete Schnittstelle
Beim Schließen der Schnittstelle, bspw. beim Beenden des Terminal-Programms
Programmatisch beim Betrieb des Urlader-Programms mspfet (Bestandteil von mspgcc)
Programmatisch beim „Suchen nach neuer Hardware“ durch den PnP-Manager
Diese Suche wird unter Windows automatisch beim Systemstart oder durch Anwenderbefehl im Geräte-Manager eingeleitet, niemals automatisch.

So ist es viel praktischer. Die Kapazität C1 bildet mit R2 eine Zeitkonstante. Diese muss groß genug sein, damit die Programmiersoftware mspfetcon fehlerfrei läuft. Mit den angegebenen Werten funktioniert es.

Für die reguläre Firmware-Funktion werden Verbindungen zu UTxD0 und URxD0 (bzw. für UART #1) benötigt. Die beiden „Hardware-Handshake“-Signale sind optional und können an beliebige Anschlusspins gelegt werden. Da die meisten MSP430 genügend Portpins haben, ist es am einfachsten, P1.1 mit UTxD0 und P2.2 mit URxD0 zu verbinden. Die Firmware muss dann bloß noch P1.1 und P2.2 als unbenutzte Eingänge behalten.

Zur Funktion von Seriellem PnP muss ein hostseitig generierter LOW→HIGH-Pegelwechsel auf RTS erkannt werden. Daraufhin sendet der Mikrocontroller des Geräte-ID-String in der fixen UART-Einstellung 1200,7,n,1. Der weitere Betrieb (insbesondere die Baudrate) ist dann gerätespezifisch und nicht durch den PnP-Standard abgedeckt.

Mögliche Modifikationen und Einsparungen⚓

Die MSP430x1xxx verwenden einen gemeinsamen Serialisierungsblock für SPI, I²C und UART. Deshalb muss man bedenken, dass, wenn man USART #0 für UART benutzt, SPI #0 faktisch unbenutzbar wird und die zugehörigen Pins SOMI0, SIMO0, and UCLK0 nur als normale Portpins brauchbar sind.

Je nach Boardlayout kann es besser sein, USART #1 zu verwenden.

Da die MSP430-UARTs keine eingebaute Hardware-Flusskontrolle haben (eher typisch für ARM-Controller), kann man für RTS und CTS beliebige Portpins verwenden. Deren Steuerung muss ohnehin in Software erfolgen. Wird kein Hardware-Handshake benötigt, kann man auch gut darauf verzichten. Die beiden frei werdenden Treiber des MAX3232 kann man für eine zweite serielle Schnittstelle verwenden.

RTS wird für den Betrieb des Seriellen PnP benötigt. Ist kein MAX3232-Kanal mehr frei, kann man auch wieder einen Serienwiderstand zur Pegelkonvertierung benutzen, also TCK mit einem beliebigen Portpin verbinden, und die Firmware-Logik invertieren.

FAQ⚓

⚓

Die von uns selbst entwickelte Steuerung auf Basis MSP430F249 soll befähigt werden die Firmware über die USB-Schnittstelle (FT232) mittels Urlader zu aktualisieren. Was ist da genau zu tun?
Im Prinzip: Einfach so anschließen! Es wird kein MAX?232 benötigt.
Falls bei Ihnen P1.1 und P2.2 bereits vergeben sind, haben Sie Pech (schieben Sie die Schuld auf den Hardware-Designer, der meine Webseite nicht gelesen hat) und können den eingebauten Urlader nicht verwenden. Sie müssen einen eigenen schreiben, der entweder kompatibel zum eingebauten ist, oder dazu noch eine (Windows-)Programmiersoftware. Wie auch immer Sie den in der Massenproduktion in den Chip bekommen! Und er muss bombensicher sein: Allzeit aktivierbar und sich selbst nicht überschreibend. Auch knapst dieser ca. 2 KByte vom Flash-Speicher weg. Beispiel-Implementationen gibt's im Internet.
Falls P1.1 und P2.2 frei ist, können Sie hier weiterlesen: Beachten Sie beim Lesen des Schaltplans, dass ein MAX?232 die Signale prinzipiell invertiert: 0V ↔ +12V und 5V ↔ –12V. Außerdem hat die angegebene Schaltung den Seiteneffekt, dass während des Hochlaufs von Windows sowie bei erzwungener Hardware-Suche (im Geräte-Manager) der Controller einige Male ins Reset geschickt wird. Je nach Anwendung kann das stören und ist meist nur für netzverbundene Geräte mit betriebsmäßiger(!) RS232-Schnittstelle sinnvoll.
Im Detail: Sie müssten erst einmal Grundsatzentscheidungen fällen:

Mit oder ohne betriebsmäßiger serieller Schnittstelle
(Wenn 0.) Mit oder ohne Hardware-Flusskontrolle (CTS und RTS) - siehe oben
Mit oder ohne Potenzialtrennung

Zu 0.:
Rein zum Programmieren (also für den nicht betriebsmäßigen Gebrauch) des FT245R benötigen Sie keine Flusskontrolle sowie keine Verbindung zu UC??TxD sowie UC??RxD. Wäre aber im allgemeinen ziemlich schade, den recht teuren FT245R-Chip nur dafür einzusetzen.
Vielleicht liegt auch ein grundsätzlicher Designfehler vor und man wäre mit einem MSP430F5xxx mit eingebautem USB und eingebautem USB-Urlader viel besser dran. (Man muss dazu gar nichts mit USB programmieren!) Anwendungsseitig ist sogar noch vorteilhaft, dass man unter Windows keinen Treiber (von FTDI) installieren muss, da der Urlader HID-basiert ist. Der Urlader muss in diesem Fall bei Netzzuschaltung mit einer Taste oder aber bei nicht Der einzige Nachteil dieser moderneren Chips ist die fehlende Möglichkeit der Potenzialtrennung.
Zu 1.:
Mit Flusskontrolle: Sie müssen RTS invertieren und an TCK führen, um zur üblichen Programmiersoftware kompatibel zu bleiben. DTR müssen Sie ebenfalls invertieren und mit dem gezeigten RC-Glied differenzieren, wie im Schaltplan zu sehen. Aber die Invertierung können Sie durch Programmierung des FR232R erschlagen. Sie können auch RTS durch den FT232R invertieren lassen; Ihre Firmware müsste dann mit dem invertierten RTS zurechtkommen.
Nur mit Flusskontrolle haben Sie die Möglichkeit, das Gerät per Serial-Plug-And-Play automatisch erkennen und enumerieren zu lassen. Wie es dann aber weiter geht, darüber hat die Welt noch nichts herausgefunden.
Ohne Flusskontrolle: Beide Invertierungen lassen sich durch die FT232R-Programmierung erschlagen, es wird kein Gatter benötigt.
Beim FT232 ohne R haben Sie den Luxus der programmierbaren Invertierungen nicht, und einen umständlichen Quarz benötigen Sie dann extra noch.
Zu 2.:
Mit Potenzialtrennung werden 4-5 Optokoppler benötigt, wo sonst bereits 2 genügen. Die zusätzlichen Koppler dürfen vom lahmen Billigtyp (CNY17 aka MB104) sein. Die Invertierung erfolgt bei gescheiter Verschaltung gratis.

⚓

Was ist bei Batteriespeisung zu beachten?

Ableitstrompfade hin zum (abgeschalteten) FT232R sind auf jeden Fall zu berücksichtigen. Dazu ist es am besten, mit einem zusätzlichen Eingangspin den Stromversorgungsstatus des FT232R zu detektieren und die Ausgänge TxD und RTS hochohmig zu schalten, wenn keine Spannung anliegt.
Häufig wird man den MSP430 dann ebenfalls in einen Zustand verringerter Leistungsaufnahme setzen, etwa für den Betrieb der Echtzeituhr mit dem 32-KHz-Uhrenquarz.
Besteht noch eine weitere externe Stromversorgung (typischerweise per Wandwarze und Hohlstecker), sollte diese ebenfalls mit einem weiteren Eingangspin detektiert werden.
Auch bei Nur-Netzstromversorgung ist das Problem der Ableitströme zum FT232R zu berücksichtigen! Ist partout kein Eingangspin mehr frei, behilft man sich mit Serienwiderständen an den Ausgängen TxD und RTS.

⚓

Was für Konsequenzen hat serielles Plug-And-Play?
Hier passiert (unter Windows) folgendes:
Was? (= PnP-Enumeration)

Aktiviert die RTS-Leitung und wackelt an der DTR-Leitung. (Dies führt bei der o.a. Schaltung zum Controller-Reset!)
Erwartet eine Antwort mit 1200 Baud, 7 Bit, keine Parität, 1 Stoppbit (kurz 1200,n,8,1)

Wo?

An allen seriellen Schnittstellen (egal ob eingebaut oder via USB-Seriell-Adapter)

Wann?

Beim Hochfahren
Beim Starten der Gerätesuche im Geräte-Manager
Was folgt?
Ist die Antwort ein einzelnes "M", wird eine serielle Maus detektiert. Das war schon um 1990 bei der Einführung der Microsoft-Maus so. Nennt sich nun Legacy-Support.
Ist die Antwort ein bestimmter Binärdaten-String mit Prüfsumme, eingeschlossen in runden Klammern, beginnt Windows mit der Gerätesuche via INF-Datei:
Häufig handelt es sich um ein externes Modem (Das ist das Geheimnis, wieso Windows angeschlossene Modems erkennt!)
Der Antwortstring:
"(" "\1\44" PnP-Revision (0x01, 0x24) "MDC0288" EISA-ID (3 Buchstaben), Produkt-ID (4 Ziffern) "\\00314159" Seriennummer "\\MODEM" Geräteklasse "\\MDC0144,ATM0096" Geräte-ID "\\ZIP 288" Anzeigetext "C4" Prüfsumme ")"
Passt zur INF-Datei mit dem Match-String:
%DeviceDesc%=Dev, SERENUM\MDC0288
Normalerweise lädt Windows eine .SYS-Datei (startet einen Dienst) — das lässt sich aber auch verändern!
Wird keine passende INF-Datei gefunden, bleibt ein unbekanntes Gerät mit Fragezeichen im Geräte-Manager stehen
Was nützt das?

Da alle seriellen Geräte die PnP-Enumeration überleben müssen, lässt sich ein bestimmtes Gerät auch „zu Fuß“ finden, ohne Fremdgeräte zu stören. Damit erübrigt sich bei entsprechender Anwendungssoftware die Notwendigkeit, eine bestimmte COM-Schnittstelle auswählen zu müssen.
Eine passende INF-Datei kann einen (interaktiven) User-Mode-Dienst unterschieben. Damit kann das angeschlossene Gerät sogar ohne eingeloggten Anwender mit Windows kommunizieren. Außerdem würde im Geräte-Manager ein vernünftiges Symbol erscheinen.
Siehe hier.