AS/400 :: Roboter :: Microcontroller :: Elektronik :: Downloads :: Links :: Seitenchronik

feedback :: home

 



 Microcontroller
 

Nitron LCD Terminal

MON08 Programmier und Debugschaltungen

Nitron Oszillator trimmen

AB32 Board

HC08 Flash Programmieren

HCS08 Controller

HCS12 Controller

HC12 Welcome Kit

TBDML HCS12 BDM Tool

Zwobots Display

 

 

 

MON08 Programmier und Debugschaltungen

   

Für die HC08 Familie läßt sich mit wenig aufwand ein Programmiergerät bauen. Dieses kann dann auch noch zu debuggen benutzt werden. Im Datenblatt der jeweiligen MCU ist dieses beschrieben. Leider ist die Beschreibung manchmal etwas unübersichtlich, weil Motorola alle Möglichkeiten, die sich aus den Entsprechenden Signalkombinationen ergeben in einer Schaltung untergebracht hat, welche je nachdem in welcher Stellung sich bestimmte Schalter befinden die eine oder andere Kombination auswählt. Desweiteren wird dort meist auch nur eine feste Frequenz vorgegeben, mit der sich dann eine Baudrate von 9600 Bps ergibt. Andere Frequenzen sind durchaus möglich,, ergeben dann jedoch andere Baudraten. In der Apllication Note AN2317 ist das ganze noch einmal etwas genauer beschrieben und noch einige Schaltungsvarianten auf. Ich werde hier grundsätzlich die Variante mit dem MAX232 für die Pegelanpassung und einem 74HCT125 um die Umschaltung zwischen senden und empfangen umzuschalten. Dieser Teil soll hier auch nicht weiter erläutert werden, weil er sowieso immer gleich ist. Grundsätzlich können die HC08 MCU´s zwischen 2 Betriebsarten unterscheiden, dem Monitor Mode und dem User Mode. Im User Mode wird die Adresse in FFFF und FFEE in den PC geladen und dort mit der Programmausführung begonnen. Beim Monitor Mode wird der Resetvektor aus der Adresse FEFF und FEFE geladen und ein Programm im ROM der MCU ausgeführt. Es gibt zwei Arten des Monitor Mode´s, den Forced Monitor Mode und den Normal Monitor Mode. Die MCU geht immer dann in den Forced Monitor Mode, wenn an den Adressen FFFF und FFFE der Inhalt FF FF steht, weil man wenn der Resetvektor nicht programmiert ist davon ausgehen kann, das die MCU noch nicht programmiert ist und kein Benutzerprogramm zum ausführen vorhanden ist. Der Forced Monitor Mode eignet sich also nur zum Programmieren von leeren MCU´s. Debuggen und umprogrammieren ist damit nicht möglich. Es müssen aber wesentlich weniger Signale auf einem Definiertem Pegel liegen als beim Normal Monitor Mode. Wenn man also mit der Softwareentwicklung fertig ist und die Chips nur noch für die Produktion brennen will langt das aus.

Um welche Signale handelt es sich ?

Je nach MCU werden hier unterschiedlich Pins verwendet. Die Funktion der Signale ist aber immer gleich. Bei manchen MCU´s fehlen einige der Signale, weil es dort bestimmte Kombinationen nicht gibt.

Vtst/IRQ : An diesem Pin Muß für denn Normal Monitor Mode eine höhere Spannung als die Betriebsspannung angelegt werden. Typischerweise 7 - 9 Volt bei einer 5 Volt MCU. Es fließt hier kein nennenswerter Strom, deshalb kann diese Spannung zum Beispiel am MAX232 abgegriffen werden.

COM : Ist meistens auf PTA0 manchmal auch auf PTB0. Über diesen Pin Kommuniziert die MCU mit der RS232 Schnittstelle. Das ganze wird im halbduplex verfahren gemacht, so das hier nur ein Pin notwendig ist. Das macht die äußere Beschaltung etwas aufwendiger aber spart MCU Pins, die evtl. für das programmieren/debuggen freigehalten werden müssen.

MOD0/MOD1 : Diese beiden Pins selektieren den Monitor Mode und müssen auf einem definiertem Pegel liegen. Motorola nutzt diese Pins noch für Interne Tests, die aber nicht weiter dokumentiert sind.

DIV4 : Wenn dieser Pin logisch High ist wird die Externe Frequenz durch 4 geteilt als Busfrequenz genutzt. Ist der Pin logisch Low, dann wird die Frequenz nur durch 2 geteilt.

SSEL : Serial Select. Bestimmt die Art und Weise wie die Security Bytes übertragen werden. Die restlichen Daten werden grundsätzlich seriell übertragen. Normalerweise werden die Security Bytes Seriell übertragen, Parallel ist auch nicht bei allen MCU´s möglich und von Motorola nicht weiter Dokumentiert.

Auf welchen Pins liegen die Signale ?

Das ist dem Datenblatt zu entnehmen. Hier ist eine Kleine aber nicht vollständige Tabelle.

GP/GT JL/JK KX MR QB/QY/QT AB32 JB16
Vtst IRQ IRQ IRQ IRQ IRQ IRQ IRQ
COM PTA0 PTA0 PTA0 PTA0 PTA0 PTA0
MOD0 PTC0 PTB1 PTB0 PTC3 PTA1 PTC0 PTA1
MOD1 PTC1 PTB2 PTB1 PTC4 PTA4 PTC1 PTA2
DIV4 PTC3 PTB3 NC NC NC PTC3 PTA3
SSEL PTA7 PTB0 PTA1 PTC2 NC NC PTE3

Was passiert denn beim Monitor Mode ?

Wenn nach einem Power on die Signale für den Monitor Mode anliegen, dann wartet die MCU auf die Übertragung der 8 Security Bytes. Dies sind die 8 Bytes von Adresse FFF6 bis Adresse FFFD. An diesen Adressen liegen die Interruptvektoren, deshalb ergeben sich die Security Bytes normalerweise aus der Anwendung die man in den MC brennt. Wenn die übertragenen Bytes mit denen die im Flash gespeichert sind übereinstimmen ist der Flash Speicher lesbar, ansonsten ist nur das RAM im Zugriff. Es ist allerdings möglich den gesamten Flash Bereich zu löschen.

Mit welcher Frequenz muß die MCU laufen, damit ich die richtige Baudrate zum Programmieren bekomme.

Motorola benutzt in den Datenblättern meist eine Frequenz von 4,1952 MHz das ergibt dann bei DIV4 auf Low eine Baudrate von 9600 Bps es sind aber auch andere Frequenzen möglich. Zu beachten ist, das zur Programmierung des FLASH Speichers der Bustakt mindestens 1 MHz betragen muß

Frequenz Bustakt Baudrate DIV4
2,4576 MHz 1.2288 MHz 4800 Low
4,9152 MHz 2.4576 MHz 9600 Low
4,9152 MHz 1,2288MHz 4800 High
7,3728 MHz 3,6864 MHz 14400 Low
9,8304 MHz 4.9152 MHz 19200 Low
9,8304 MHz 2,4576 MHz 9600 High
14,7456 MHz 7,3728 MHz 28800 Low
14,7456 MHz 3,6864 MHz 14400 High
19,6608 MHz 4,9152 MHz 19200 High
29,4912 MHz 7,3728 MHz 28800 High

Ich habe auch erfolgreich eine Kommunikation mit 19200 Bps mit einem 20 MHz Oszillator hinbekommen, es ist also gut möglich das 5,10,15 und 30 MHz auch funktionieren, ohne das es zu Kommunikationsproblemen kommt.

Wie sieht das ganze dann aus ?




Muß ich denn wirklich soviele Ports opfern ?

Nicht unbedingt. Die Ports müssen nur beim Reset auf den Definierten Pegeln liegen. Danach können die Ports außer COM ( PTA0) benutzt werden. Hier gibt es unterschiedlich Möglichkeiten. Entweder man schaltet die entsprechenden Pins mit Hilfe von Schaltern/Jumpern um oder man paßt die Verwendung der Ports den geforderten Signalen an. Ports die auf High Level liegen müssen können als Inputs die gegen Low geschaltet werden verwendet werden. Hierzu sollte ein Pullup Widerstand von ca 10 KOhm benutzt werden. Ebenfalls können diese Ports auch als Outputs die Low aktiv sind verwendet werden. Auch hier sollte ein Pullup von ca 10 kOhm verwendet werden. Ports die ein Low Signal haben können analog dazu als aktiv Low betrieben werden. Falls man den Interrupt eingang benutzen will, wird es etwas komplizierter. Dann muß die Spannung Vtst an den Reset Eingang gelegt werden bevor sie vom IRQ Eingang entfernt wird. Danach kann man den IRQ Eingang auch beim Debuggen benutzen. Bei den Nitrons ( 68HC908QYX 68HC908QTX ) kann man auch den User Monitor verwenden, nachdem er einmal einprogrammiert wurde. So etwas gibt es für die anderen MCU´s bisher leider nicht. Wenn es nur um das Programmieren geht dann hilft Motorolas AN2295 Developers Serial Bootloader. Eine andere Möglichkeit ist auch noch der Pony Monitor von L3Systems, der Programmieren und Debuggen zuläßt.

Wenn ich zum Programmieren sowieso einen Oszillator brauche, warum soll ich dann einen Quarz verwenden um die MCU zu takten ?

Mit dem Quarz kann über die PLL der Bustakt während die MCU läuft verändert werden. Das kann auf mehrere Arten nützlich sein. Man kann die MCU bremsen um den Stromverbrauch zu reduzieren. Man kann aber auch auf 8,2 MHz Bustakt hochgehen wenn man die Geschwindigkeit braucht. Zwischendurch kann man die PLL umprogrammieren, um auf eine Frequenz zu kommen, mit der sich einfach gängige Baudraten für die Serielle Schnittstelle erzeugen lassen. Falls die MCU ein TBM Modul hat, so arbeitet dieses auch nur mit dem Quarz zusammen.

 

 

 

 
     

 

   © 2005 by Eckhard Gosch •  eckhard@eckhard-gosch.de