RAM! Mehr RAM!

RAM Add-On Board für das Motorola B32EVB

von Oliver Thamm

Erschienen (leicht gekürzt) in Design & Elektronik
Themenheft Embedded Systems - Software-Entwicklung - Juli '99

Bedingt durch das zeitkritische Businterface des MC68HC912B32 gestaltet sich das Anschalten einer Speichererweiterung an das Motorola Evaluation Board nicht unkompliziert. Der vorliegende Beitrag zeigt, welche Probleme dabei entstehen und wie man sie in der Praxis lösen kann. Die Bemühungen des Anwenders werden belohnt durch die starke Vereinfachung von Download und Test eigener Applikationsprogramme auf dem B32EVB.

Die HC12 Mikrocontrollerfamilie von Motorola gehört zweifellos zu den spannendsten Neuvorstellungen im 16 Bit-Bereich der letzten Jahre. Die ausbalancierte Architektur der Bausteine - leistungsstark, zugleich aber nicht zu komplex - lockt nicht nur bisherige HC11 Anwender, sich intensiver dem HC12 zuzuwenden.

Für den Einstieg, also für die Evaluierung und die ersten Softwaredesignschritte, bietet Motorola ein Evaluation Board auf der Basis des 68HC912B32 an. Dieses Evaluation Board (im folgenden kurz B32EVB genannt) zeichnet sich durch einfache Handhabbarkeit aus. Auf der Platine im "Urlaubsfotoformat" (ca. 9 cm x 13 cm) befindet sich, abgesehen von der 'B32 MCU, noch ein RS232 Pegelwandler nebst Sub-D9 Buchse als Schnittstelle zum PC des Entwicklers. Für eigene Erweiterungen steht ein ca. 35 qcm umfassendes Lochrasterfeld zur Verfügung. Neben essentiellen Peripheriekomponenten, wie Quarzbeschaltung (16 MHz), Resetcontroller (MC34164), diversen Pull-Up Widerständen, Stützkondensatoren und einem Resettaster, sind weiterhin einige Jumper und Steckverbinder vorzufinden.

Modus operandi

Mit den Jumpern W3 und W4 wird die Betriebsart des B32EVB eingestellt, Tab. 1 faßt die möglichen Varianten zusammen. In der normalen EVB-Betriebsart wird nach Reset ein Monitorprogramm aktiv. Es ist im internen Flashspeicher des HC912B32 untergebracht. Die Bedienung erfolgt mit 9600 Baud über die serielle Schnittstelle, dazu verbindet man einfach das B32EVB mittels eines 1:1-belegten Sub-D9 (Verlängerungs-) Kabels mit dem Host-PC. Auf der PC-Seite benötigt man als Software lediglich ein einfaches Terminalprogramm. Gut geeignet ist z.B. das "gute alte" TERMINAL.EXE aus Windows 3.1x, welches offenbar auch unter Win9x klaglos funktioniert und überraschenderweise sogar über eine spezielle Handshakefunktion verfügt, welche für die Flash-Programmierung auf dem Evaluation Board benötigt wird.

W4	W3	Mode	Beschreibung
0	0	EVB	Normale EVB-Betriebsart
0	1	JMP-EE	nach Reset wird Anwenderprogramm im EEPROM gestartet
1	0	POD	Modul arbeitet als BDM12-Pod
1	1	PGM	Flash-Programmiermodus

Tab.1: Betriebsarten des B32EVB

Eine weitere Betriebsart des B32EVB ist der sogenannte POD-Modus. In dieser Variante, wiederum selektiert durch die Jumper W3 und 4, scheint das D-Bug12 Monitorprogramm zunächst wie im EVB-Mode gewohnt zu starten. Alle Zugriffe auf Speicher, Ports und CPU-Ressourcen finden nun aber nicht mehr on-board auf Basis der eigenen MCU statt, sondern werden über den Background Debug Mode Ausgang des B32EVB (W12: BDM OUT) von einem externen Target eingelesen. Das Target kann ein nahezu beliebiges HC12-System mit entsprechendem BDM-Eingang sein. Der angeschlossene Controllertyp läßt sich über ein D-Bug12 Kommando genauer spezifizieren. In der POD-Betriebsart fungiert das Evaluation Board lediglich als Bindeglied zwischen Zielsystem (Target) und Host-PC. Das "Look & Feel" verändert sich gegenüber dem EVB-Modus kaum - der Anwender hat es scheinbar immer noch mit einem ROM-Monitor zu tun. Die dazu benötigte Software (D-Bug12) belegt aber - und das ist der entscheidende Unterschied - keine Ressourcen des Zielsystems. Über das BDM12 Single Wire Background Debug Mode System und die interessanten Möglichkeiten, die sich dem Entwickler damit bieten, ist an anderer Stelle bereits ausführlich berichtet worden [1,2,3].

Die anderen beiden Betriebsarten des B32EVB sollen der Vollständigkeit halber noch erwähnt werden: Zunächst einmal ist es möglich, direkt nach Reset ein Anwenderprogramm im internen EEPROM des HC12 zu starten (JMP-EE Modus). Desweiteren gewährt der Programmiermodus (W3 und W4 in Stellung "1") die Möglichkeit, die internen, nichtflüchtigen Speicher (EEPROM und Flash-Memory) zu löschen und neu zu beschreiben. Für die Programmierung des Flash-Arrays benötigt man eine extern bereitgestellte Programmierspannung von knapp 12V und natürlich das zu ladende Speicherabbild in Form einer S-Record Datei. Die letzten 2 KB des Flash-Bereiches sind grundsätzlich vor Überschreiben geschützt ("Boot-Block").

Turn Around

In der praktischen Handhabung ist das fortgesetzte Neuprogrammieren des Flashspeichers im Verlauf einer Applikationsentwicklung recht mühselig. Um eine neue Programmversion zu laden, muß man stets eine Reihe von Bedienschritten ausführen. Das umfaßt das Umstecken mehrerer Jumper, das Anlegen (und Kontrollieren!) der Programmierspannung, den eigentlichen (einige Zeit erfordernden) Programmiervorgang und schließlich das Herstellen der normalen Betriebsbedingungen (Programmierspannung aus, Jumper zurückstellen etc.).

In der infantilen Phase einer Applikation kann der Anwender noch auf begrenzte EEPROM- oder RAM-Ressourcen zurückgreifen. Da diese HC12-internen Speicherbereiche aber jeweils nur einige hundert Bytes umfassen, sind die sich bietenden Möglichkeiten alsbald ausgereizt. Bleibt nur die Möglichkeit, den Applikationscode doch in den Flashspeicher zu laden. Zusätzlich zu den o.g. Unannehmlichkeiten, die mit der Flashprogrammierung einhergehen, ergibt sich nun noch das Problem, daß man nicht mehr auf die Monitorsoftware zurückgreifen kann. Schließlich bedeutet das Laden das Anwenderprogramms zugleich das Löschen des D-Bug12 Monitor, der sich bei Lieferung des B32EVB im Flashspeicher befand.

Ein weiterer Aspekt ist die Anzahl der garantierten Programmierzyklen. Motorola spezifiziert hier einen sehr geringen Wert. Nur einhundertmal darf der Flash reprogrammiert werden. Das gilt natürlich über den gesamten Bereich aller zulässigen Betriebsbedingungen, und es ist bekannt, daß insbesondere die Temperatur eine entscheidende Rolle spielt. Wenn man sich andererseits an die Vorgaben hält... 100 Software-Durchläufe sind innerhalb einer Programmentwicklung sehr schnell erreicht.

Schnelle Busse

Kurz gesagt: Das B32EVB ist zwar eine hübsche Evaluation-Plattform, man hat nur leider keinen Platz für eigene Software. Zum Glück verfügt der HC912B32 über ein externes Businterface. Dieses wird durch die Ports A und B realisiert. Zusätzlich werden einige Steuerleitungen benötigt, die der 'B32 auf Port E bereitstellt. Was liegt näher, als hierüber einen zusätzlichen RAM Baustein anzuschließen?

Beim Blick in die Datenblätter erleidet mancher bisherige HC11-Anwender zunächst einen Kulturschock. Das Businterface des HC912B32 arbeitet (im Expanded Wide Mode) mit 16-Bit Adressen und 16-Bit Daten im Multiplexverfahren. Bei einem Bustakt von 8 MHz holt sich die MCU also zwei Byte in 125 ns. An den Einsatz von Low-Power sRAMs mit 70 bis 100 ns ist dabei nicht zu denken - erforderlich sind Zugriffszeiten, die eindeutig in die Domäne der Cache-RAMs fallen, d.h. unter 20 ns! Das Timingdiagramm in Abb. 2 zeigt, wie diese ungewöhnlichen Anforderungen zustande kommen (Quelle: [4]).

Abb.2: Multiplexed Expansion Bus Timing

Der Bustakt ECLK ist gewissermaßen der Herzschlag des Systems. Eine Periode (1) ist 125 ns lang, vorausgesetzt der maximal zulässige Quarztakt von 16 MHz wird verwendet. Busaktivitäten spielen sich im Wesentlichen in der H-Phase (3) des ECLK ab.

Mit der steigenden ECLK-Flanke sind die Adressen auf dem gemultiplexten Adreß-/Daten-Bus gültig. Sie müssen in ein 16-Bit Latch übernommen werden. Wenn es sich um einen Lesezyklus (Wort) handelt, ist R/W High und /LSTRB ebenso wie das niederwertigste Adreßsignal A0 Low (vergl. Tab. 2).

/LSTRB	A0	R/W	Art des Zugriffs
1	0	1	8 Bit Read - gerade Adresse
0	1	1	8 Bit Read - ungerade Adresse
1	0	0	8 Bit Write - gerade Adresse
0	1	0	8 Bit Write - ungerade Adresse
0	0	1	16 Bit Read - gerade Adresse
1	1	1	16 Bit Read - ungerade Adresse (nur interner RAM)
0	0	0	16 Bit Write - gerade Adresse
1	1	0	16 Bit Write - ungerade Adresse (nur interner RAM)

Tab.2: Byte- und Wortzugriffe vs. /LSTRB und A0

Das Signal /DBE (Data Bus Enable) zeigt an, daß ein externer Busteilnehmer nun seine Daten auf den Bus geben darf. /DBE wird aktiv spätestens 37 ns (24) nach der steigenden ECLK Flanke. Geht man davon aus, daß die H-Zeit von ECLK insgesamt 67 ns beträgt, so verbleiben noch 30 ns bis zur fallenden ECLK Flanke. Das ist genau der Wert, der im Datenblatt als Minimum für die "Data Read Setup Time" (11) gefordert wird. Der aufmerksame Leser wird nun stutzig, denn hier kann etwas nicht stimmen. Drei Deutungen bieten sich an:

Motorola fordert eine RAM-Zugriffszeit von 0 ns
das Signal /DBE ist nutzlos
oder der Timingparameter (11) ist übertrieben

Im ersten Fall liegt die Vermutung nahe, Motorola entwickelt an einem neuen High-Speed RAM für den WARP-Antrieb der zukünftigen Marsmissionen. Kann sein. Punkt zwei klingt da schon wahrscheinlicher, zumal nach näherer Untersuchung des Stretching-Mechanismus des Controllers. Der 'B32 kann nämlich Buszyklen verlängern, d.h. er kann das Timing der ECLK H-Phase strecken! Aber zu früh gefreut: Das Stretching führt zwar dazu, daß die Address Hold Time (8) länger wird, aber die aktive /DBE-Zeit (25) wird dabei nicht verlängert! Dumm gelaufen, sagt da der Anwender, und spült (11) mit einem Weißbier aus seinem Kurzzeitgedächtnis. Wohl dem Entwickler, der die Funktionsfähigkeit seiner Designs nicht theoretisch untermauern muß...

RAM dran

Überraschenderweise zeigt sich: Ein RAM-Zusatz für das B32EVB stellt nicht nur eine nützliche Erweiterung dar, sondern befriedigt zudem akademischen Forscherdrang. Wir stellen die Theorie auf, 20 ns Data Setup Zeit reichen aus und überprüfen es am praktischen Beispiel.

Abb. 3 zeigt den Schaltplan der RAM-Erweiterung. Da es sich um ein RAM Board für den 'B32 handelt, lautet die Kurzbezeichnung (etwas kämpferisch) RAM.Bo32.

Abb.3: Schaltplan Speichererweiterung (für vergrößerte Version bitte anklicken)

Zentrales Element in der Schaltung ist IC3, ein schneller statischer RAM mit 64K x 16 Bit und 15 ns Zugriffszeit. Der hier eingesetzte Typ TC551664 stammt von Toshiba, andere Hersteller wie NEC und IDT bieten ähnliche Bausteine an.

Die nur zeitweise auf dem gemultiplexten Bus befindlichen Adreßinformationen werden durch IC1 und IC2 gelatcht. Diese Vorgehensweise ist bekannt vom HC11 und verschiedenen anderen Mikrocontrollerfamilien. Als Übernahmetakt benötigen die Latches eine H-L-Flanke, diese wird durch Invertieren von ECLK gewonnen. Das selbe Signal wird verwendet als low-aktives Chip-Enable Signal für den RAM.

Die Ausgänge des RAM werden, im Falle eines Lesezugriffs, durch /DBE freigegeben. Diese Zugriffsart ist besonders schnell; bereits nach 8 ns (worst case) stellt der RAM die Daten bereit, vorausgesetzt die Adressen liegen - wie in unserem Fall - bereits einige Nanosekunden zuvor an (siehe [5]).

Der eingesetzte RAM-Baustein hat eine Kapazität von 128 KByte. Kleinere Bausteine sind kaum mehr handelsüblich, andererseits umfaßt der Speicheradreßraum des HC912B32 nur 64 KB. Um die zusätzliche Kapazität des RAM nicht gänzlich zu verschenken, kann die Adreßleitung A15 des RAM mit dem Portsignal PS3 der MCU verbunden werden. Nach Aktivierung von PS3 als Ausgang kann man so zwischen zwei 64 KB Speicherbänken umschalten.

Die in der Zusatzschaltung benötigten Signale werden über vier Steckverbinder (P2, 3, 4 und 6) zugeführt, welche auf dem Basisboard das Controller-IC umgeben. Sie ermöglichen den Zugriff auf alle 80 Controllerpins. Die RAM-Erweiterung kann somit als kompakte Platine einfach auf diese vier Steckverbinder aufgesteckt werden.

Power On

Liegt die Zusatzschaltung dann bereit (in [6] sind auch Layout und Bestückungsplan der doppelseitigen Platine wiedergegeben), kann man sie auf das B32EVB aufstecken und inbetriebnehmen. Bereits vor dem ersten Einschalten sollte man jedoch auf den Rat des (leid-) erfahrenen Praktikers hören, und zunächst parallel zur Betriebsspannungsbuchse eine Suppressordiode anschließen, z.B. eine P6KE6,8 (Anode an GND). Diese Vorsichtsmaßnahme zahlt sich beim ersten versehentlichen Verpolen oder Überhöhen der Betriebsspannung aus. Der Aufwand, die SMD-montierte MCU im TQFP80-Gehäuse auszutauschen, ist dagegen nicht unbeträchtlich. Und der spontane Neukauf des preiswerten Motorola-Tools beim Distri scheitert oftmals an nervenzehrenden Lieferzeiten...

Nach Anlegen der Betriebsspannung meldet sich der Monitor - hoffentlich - wie gewohnt. Man kann nun Monitorkommandos eingeben, wie z.B. den Display Memory Befehl. Beim Zugriff auf die neugewonnenen RAM-Bereiche zeigt sich aber alsbald, daß es noch einige Hindernisse zu überwinden gilt.

Die MCU startet auf dem B32EVB stets im Single Chip Mode. Der Flashspeicher belegt die oberen 32 KB, unterhalb $1000 liegen Registerbereich, interner RAM und EEPROM. Das externe Businterface ist in dieser Betriebsart nicht aktiv, es läßt sich aber durch Ansprechen des MODE Registers der MCU nachträglich freigeben. Das MODE Register läßt sich (in den Normal Modes der MCU) jedoch nur einmal nach Reset beschreiben. Da ein solcher Zugriff bereits im Startupcode des Monitorprogramms passiert, läßt sich im Nachhinein interaktiv nichts mehr ausrichten. Die Änderung muß also direkt im Monitorcode vorgenommen werden.

Patchwork

Zum Glück ist zumindest die Startup-Sequenz in den Unterlagen zum B32EVB dokumentiert. Somit ist es einfach, die benötigte Änderung einzubauen. Listing 1 zeigt die betroffene Quelltextpassage.

;   Enable pipe signals, E, low strobe and read/write in port E
;   PIPOE, NECLK, LSTRE and RDWE are write once in normal modes
;   PEAR [ARSIE :CDLTE :PIPOE :NECLK !LSTRE : RDWE : 0 : 0 ] $--0A
;
            ldaa #$2c                   ; prevent later protection lock
            staa *PEAR                  ; PROTLK is write-once

;   Without changing modes, enable internal visibility
;   MODE [SMODN : MODB : MODA : ESTR ! IVIS : 0 : EMD : EME ] $--0B
;
            bset *MODE,$08              ; set IVIS
;           Change this to:
;           bset *MODE,$68              ; set IVIS + switch to Expanded Mode

Listing 1: Änderung im D-Bug12 Monitor

Diese Änderung erfordert ein komplettes Neuladen des Monitorcodes, denn im Flashspeicher lassen sich, im Gegensatz zu RAM und EEPROM, keine Einzelbytes ändern. Statt dessen muß das Flash-Array (bis auf den Boot-Block) gelöscht und mit dem gepatchten D-Bug12 Code neu geladen werden.

Nach der beschriebenen Modifikation kann man endlich den neu gewonnen Komfort ausgiebig genießen und auf ca. 28 KB zusammenhängenden RAM-Bereich als Code- und Datenspeicher zurückgreifen. Das funktioniert auch hervorragend - bis man ein Programm mit Interruptfunktionen testen will.

Die Sache mit den Interruptvektoren ist ja recht schnell erklärt: Kurz vor dem Ende der Memory Map hat jede Interruptquelle einen zwei Byte umfassenden Interruptvektor. Dieser Vektor verweist auf jene Stelle im Anwenderprogramm, an der die zugehörige Interrupt-Service-Routine startet. Leider sind diese (recht variablen) Interrupt-Vektoren im (recht unvariablen) Flash-Bereich angesiedelt.

Zwar hat Motorola im D-Bug12 Monitor eine Möglichkeit vorgesehen, die User-Interruptvektoren zu ändern. Beim Versuch, diese über drei Ecken verbogenen Zeiger zu benutzen, habe ich aber schon Hochschulprofessoren verzweifeln sehen (Gordon "D-Bug12" Doughman möge mir diesen Einwurf verzeihen). Einfacher wäre es, wenn die Vektoren nicht im Flash, sondern im RAM plaziert wären. Oder, wenn gleich an der Stelle von Flash RAM wäre.

Das Zusatzboard bietet gleich zweimal 64 KB RAM, da sollte es leicht sein, den Inhalt des Flashspeichers nach jedem Reset in den RAM umzukopieren. Der (interne) Flash hat Vorrang vor dem (externen) RAM. Um an den "dahinter" liegenden RAM zu gelangen, muß man den Flash disablen. Hierzu dient das ROMON Bit im Steuerregister MISC, welches aber nicht beliebig modifizierbar ist. Nach Reset im Normal Single Chip Mode ist ROMON=1, danach ist es nur einmal beschreibbar. Ein Ablauf wie: "Byte im Flash lesen, Flash abschalten, Byte im RAM schreiben, Flash wieder einschalten" ist also nicht realisierbar.

An dieser Stelle hilft ein Trick weiter, den wahrscheinlich nur erfahrene (Ex-) HC11-Anwender parat haben. Schon beim 11er war das Memoryinterface so ausgebildet, daß keine Unterscheidung zwischen internen und externen Zugriffen vorgenommen wurde. Ein Lesezugriff auf eine interne Adresse (z.B. auf den internen RAM) war auch am externen Bus "sichtbar". Die MCU hat den Vorrang der internen Ressourcen einfach dadurch geregelt, daß die Information vom internen Bus bevorzugt wurde. Dadurch führte ein interner Schreibzugriff schon beim HC11 stets auch immer zu einem externen Schreibzyklus - fatal z.B. dann, wenn man im gleichen Adreßbereich "außen" einen EEPROM ohne Schreibschutz am Bus hatte.

Und genau diesen "Bug" erklären wir hiermit zum Feature. Das Umkopieren vom Flashspeicher in den externen RAM geht also auf folgende einfache Art vonstatten: Byte an Adresse X vom internen Flash lesen, an die selbe Adresse X zurückschreiben (dabei "versehentlich" auch im externen RAM wirksam), Adresse erhöhen usw. usf. Listing 2 zeigt die überaus kurze Kopierfunktion.

;---- Copy Flash to RAM -----------
;
            ldx   #$8000
_flash2ram: movw  0,x, 2,x+
            tbne  x, _flash2ram
;
;---- 7 Byte, 8 Takte pro Wort ----

Listing 2: Kopierroutine Flash/RAM

Spurensuche

Zum Abschluß sollen noch einige Messungen vorgestellt werden, die an der realen Hardware, also B32EVB mit aufgestecktem RAM.Bo32, vorgenommen wurden. Sie geben einen (halbwegs) repräsentativen Eindruck über die tatsächlichen Abläufe auf dem Systembus, in Ergänzung zu den relativ abstrakten Timingdiagrammen in [4]. Als Meßgerät diente ein 1 GSa/s Logicanalyzer von HP, die Messungen wurden bei 5 Volt Betriebsspannung und Zimmertemperatur vorgenommen. Auf dem Motorola Board befand sich ein PC68HC912B32CFU8 (Maskenrevision 2H91F). PB0 bis PB2 sind die drei niederwertigsten Bits des gemultiplexten Adreß-/Daten-Busses. Die Zeitbasis ist abgebildet mit 20 ns pro Teilstrich.

Abb.4: Timingdiagramm Read-Zyklus

Abb. 4 zeigt einen Lesezugriff der MCU auf Adresse $xxx0; gelesen wurde $xxxF. Der Buszyklus beginnt bei Markierung A. Nach 35 ns zeigt sich an Position B ein Spike, offensichtlich legt die MCU hier die Adressen für diesen Zyklus auf den Bus. Das bedeutet, die Adressen liegen schon länger als 25 ns vor der steigenden ECLK Flanke an. Das ist ungefähr der gleiche Zeitpunkt, zu dem auch R/W und /LSTRB wechseln (hier ist eine solche Änderung nicht vorhanden, aber in der folgenden Abbildung).

Das ECLK Signal wird durch das AHC-Gatter negiert, dabei ergibt sich eine Verzögerung von 4 ns (C). /ECLK dient dazu, die Adreßinformation in die Latches IC1 und IC2 zu takten. Gleichzeitig dient es als Chip-Enable Signal für den RAM IC3.

33 ns nachdem ECLK auf H-Pegel gewechselt ist, aktiviert die MCU das Data Bus Enable Signal /DBE (Markierung D). Nach weiteren 6 ns legt der Fast Static RAM seine Dateninformation auf den Bus (E). /DBE bleibt für weitere 23 ns Low. Schließlich schaltet /DBE zum gleichen Zeitpunkt wie ECLK um (F). Ein interessantes Detail am Rande: Der durch das AHC-Gatter hervorgerufene Delay des /ECLK Signals ist mit einer H-L Flanke am Eingang weitaus geringer (kleiner als 1 ns) als im entgegengesetzten Fall (4 ns).

Abb.5: Timingdiagramm Write-Zyklus

Die zweite Aufzeichnung (Abb. 5) zeigt einen Schreibzugriff. Die MCU schreibt $xxx0 auf Adresse $xxxE. Deutlich sichtbar hier: die Adressen werden zum gleichen Zeitpunkt (B) gültig wie das R/W-Signal, also nicht erst kurz vor der L-H Flanke des ECLK, wie man es anhand des Datenblattes vermuten könnte. Die Zeit von der steigenden ECLK Flanke bis zur Ausgabe der Daten durch die MCU beträgt hier 39 ns (Markierung E). Das ist exakt der selbe Umschaltpunkt wie im Read-Diagramm zuvor! Alles in allem scheint es, als ob der HC12 auf dem B32EVB mit der angeschlossenen RAM-Erweiterung prächtig zurecht kommt.

Wenn Sie selbst HC12 Erfahrungen sammeln wollen: Verschiedene Entwicklungstools für den HC12, u.a. das Motorola B32EVB und die hier vorgestellte Hardwareerweiterung, sind bei Elektronikladen | ELMICRO erhältlich. Eine umfangreiche Sammlung von Ressourcen rund um den HC12 findet man in [6].

Literatur:

Sibigtroth/Thamm: Nabelschnur - Single-wire Background Debug Mode Interface des 68HC12; Elrad 11/96, S. 40ff.
Thamm, Oliver: HC12-Entwicklung; Design & Elektronik 6/97, S. 61f
Thamm/Sibigtroth: Zugang - Background-Debug-Interface mit HC12 für HC12; Elrad 6/97, S. 34ff.
Motorola, Inc.: MC68HC912B32 Electrical Characteristics (Ausgabe 19/3/98)
Toshiba: TC551664BJ/BFT-12,-15 Data Sheet
HC12 Web
Publikationsliste
Thamm, Oliver (Hrsg.): Hip Hop HC11 - Das Praxisbuch zur 68HC11 Mikrocontrollerfamile; Electronic Media, Detmold 1995

Nachtrag

Nach Fertigstellung des Manuskripts erhielt ich noch einen Vorschlag von Dan Miner. Seine Idee bestand darin, die bislang ungenutzten drei NAND Gatter für eine Schaltungserweiterung zu verwenden. Die Erweiterung zielt darauf ab, im Bedarfsfall die oberen 32KB des RAMs schreibzuschützen. Zur Aktivierung des Schreibschutzes wird eine weitere Portleitung (PORTS[2]) benutzt. Die Änderungen der ursprünglichen Schaltung sind im folgenden aufgelistet:

Definitionen:
A15 = IC2 Pin 12 (und IC3 Pin 19)
R/W = P4 Pin 16
/WE = IC3 Pin 17
WP  = P3 Pin 3 = HC912 PS2 = Write Protect line

Verbindung zwischen R/W und /WE auftrennen
Alle Masseverbindungen unbenutzter Eingänge von IC4 auftrennen
R/W mit IC4D Pin 12 und IC4D Pin 13 verbinden (Erzeugung von W/R)
A15 mit IC4B Pin 4 verbinden
WP mit IC4B Pin 5 verbinden
IC4B Pin 6 mit IC4C Pin 9 verbinden
IC4D Pin 11 (= W/R) mit IC4C Pin 10 verbinden
IC4C Pin 8 mit IC3 Pin 17 (= /WE) verbinden

Wahrheitstabelle:
PS2  A15  R/W  /WE
 0    0    0    0
 0    0    1    1
 0    1    0    0
 0    1    1    1
 1    0    0    0
 1    0    1    1
 1    1    0    1   *** Wenn PS2=1 und A15=1, dann SRAM nicht beschreiben!
 1    1    1    1

Im Startup Code muß man wie folgt vorgehen:

Setze WP (PS2) als Ausgang auf Null
Kopiere Inhalt des Flashspeichers Inhalt in den SRAM
Setze WP (PS2) = 1 (Schreibschutz für SRAM $8000-$FFFF)
Schalte Flashspeicher ab

Diese Ergänzung bringt den Vorteil, daß ein fehlerhaft arbeitendes Programm nicht versehentlich den Monitor Code verändern kann. Um dennoch (gewollte) Änderungen vornehmen zu können, muß man nur die Portleitung PS2 (WP) temporär auf Null schalten.

Der neue, mit allen Änderungen ausgestattete Schaltplan ist unten dargestellt. Durch Einbau der Lötbrücke BR2 kann man zwischen der alten und neuen Methode zur Write-Enable Generierung umschalten.

Schaltplan V1.1 (für vergrößerte Version bitte anklicken)

Änderungen im D-Bug12 Monitor

Damit die Hardwareerweiterung funktioniert, müssen noch einige Änderungen im Monitorcode vorgenommen werden. Laden Sie dazu diesen Patch D für D-Bug12 V2.02. Der Patch realisiert einen modifizierten Monitor Startup Code, welcher den Inhalt des Flash-Speichers in den RAM kopiert und zudem die Write-Protect Leitung PS2 entsprechend den o.g. Anforderungen bedient. Die geZIPte Datei enthält den Quelltext, damit Sie alle Änderungen/Ergänzungen nachvollziehen können.

Schließlich muß der neue Monitor auf das B32EVB geladen werden. Das geschieht so:

Jumper W3 und W4 auf dem B32EVB auf "1" setzen, Reset drücken
Programmierspannung an W8 "VPP Input" legen (vorsichtshalber nicht über 11.8V! - bitte ggf. das Datenblatt zur jeweils vorhandenen Maskenrevision des Chips heranziehen!!!)
W7 von VDD auf VPP stellen
Flash Speicher löschen (der Boot Block bleibt dabei erhalten)
Die neue S19 Datei in den Flash programmieren
W7 zurück auf VDD setzen, Programmierspannung abschalten
W3 und W4 auf "0" setzen, um den EVB Mode zu aktivieren
Reset drücken und - nichts wird passieren, falls Sie vergessen haben, zuvor die RAM.Bo32 Platine aufzustecken :-)

Hier endet der Projektartikel - Viel Erfolg beim Ausprobieren!

Links

URL dieser Veröffentlichung: http://hc12web.de/due9907/
English Version (containing additional information!)
Oliver Thamm's HC12 Web: http://hc12web.de