mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Motorola MC68332 und BD32


Autor: Tobias Plüss (hubertus)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hallo Forum,
Wie einige von euch wissen, habe ich vor einiger Zeit versucht, mit dem 
MC68000 ein Board zu entwickeln. Daraus wurde leider nichts, da dies 
viel zu aufwändig ist. Stattdessen konnte ich mir in der Firma ein paar 
MC68332 Mikrocontroller abkupfern. Die Dinger sind neu, sollten also 
funktionstüchtig sein. Nun - ich habe ein Board gelayoutet und das 
sauber ätzen lassen. Heute habe ich das ganze mal bestückt und gelötet - 
siehe da, es funktioniert NICHT. Also ich denke, prinzipiell sollte es 
wohl schon gehen, aber ich kanns nicht testen, weil:
Als Programmspeicher habe ich zwei 512kB SRAMS vorgesehen. Nun könnte 
man ja mit dem Background Debugger, den Motorola anbietet, ein Programm 
in dieses RAM runterladen. Ud genau hier liegt das Problem:
Starte ich BD32 (mit am Parallelport angeschlossenem Board und 
eingeschalteter Speisung), so meint BD32 immer, der Prozessor befinde 
sich im RESET-Status. Und das, obwohl RESET nicht aktiviert ist...
Ich weiss nun nicht, obs am Board oder an Windows XP liegt, bekanntlich 
blockiert das ja Hardwarezugriffe (Ich habe aber ein Programm namens 
AllowIO gefunden, mit dem man dies aufheben können sollte).
Was meinen die MC68332-Experten unter euch? Ist meine Schaltung komplett 
falsch? Oder liegt der Fehler bei Windows (windoof)?

Für eine diesbezügliche Auskunft wäre ich absolut froh.
Es grüsst
    Tobias


Beilage: Schema meines Boards

PS: Den Verdrahtungsfehler auf Seite 2 des Schamas habe ich bereits 
bemerkt ;) und natürlich auf der Leiterplatte korrigiert; das Schema 
habe ich aber unverändert gelassen.

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ich dir sagen kann, ist der einfache BD32 Adapter lief nie wirklich 
stabil bei mir. Gab dazu damals viele Vorschläge AHCT32 und 74 
einzusetzen. Das PC Timing spielt eine große Rolle dabei. Zu meiner Zeit 
lief das einfach unter DOS - bzw W95, aber ich habe relativ zeitig auf 
einen Bootloader und andere Debugmethoden umgestellt, um den BD32 zu 
umgehen.



Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wenn ich das Recht sehe, hast Du den Pin TSC (Pin 80) auf Masse gezogen, 
damit gilt: The inactive state of this pin is 5 Volts. Pulling it low 
enables special test mode.

Sollte zwar noch nichts tun, aber na wer weiss?

Hast Du geschaut, ob der Reset wirklich anliegt - vielleicht wird er vom 
BD32 nicht zurückgesetzt?

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo tobias,
verzeih meine frage aber was bewegt dich auf so ein "altes" pferd wie 
den 68332 zu setzen?
nimm doch einen arm7 mit integrierten speicher (flash und sram) und git 
ist's.

gruss
gerhard

Autor: Neubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hey,


habe mich in meiner vergangenheit viel mit dem bdm32+68k geärgert.

-> zum debuggen haben wir immer einen hitex-debugger genommen
-> bdm32 wurde eigentlich nur zur inbetriebnahme verwendet, wobei wir 
damals immer auf einen uralt (486er) laptop mit DOS zurückgegriffen 
haben. verbindung  zum bdm via winxx mittels "PortIO" (ähnliches tools 
wie deins wahrscheinlich) wobei dies auch immer sehr schwierig war.
die timings der original bdm-software wurden offensichtlich nicht 
mittels des pc-system-timers gelöst sondern mit irgendwelchen 
delay-varianten.
auch der betrieb des bdm32 unter dos mit schnelleren rechnern 800er o.ä. 
ging oftmals nicht, da wiederum hier einfach der rechner zu schnell war 
-> delay geschichte

... mein vorschlag : mittels uralt-rechner (486, 100mhz) + DOS versuchen 
eine korrekte verbindung zu bekommen

-> wenns funktioniert :) ... viel spass mit 20jahre alter technologie; 
ansonsten ab in den rundordner !!!



-->> warum wirklich den betagten 68k verwenden : arm-controller mit 
flash+ram intern = 10x schneller, kein sinnloses 10fach-layer layout, 
winxx entwicklungsumgebung, aktueller compiler, .....


Neubi

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Damit hier kein falscher Eindruck entsteht, der '332 ist wohl ein 
Produkt aus den 90ern, aber funktioniert steinstabil und ist immernoch 
aktuell.

Der Kern (CPU32) wird heute synthetisiert von vielen Firmen für 
Neuentwicklugen eingesetzt. Auch eine Secondsource von Atmel ist 
verfügbar.

Wo er hinpasst ist er auch heute noch eine gute Wahl.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo ihr,
Danke erstmal für die Auskünfte.
Warum ich den 68332 einsetze: Ganz einfach, in der Firma haben wir auf 
dem das Programmieren gelernt. Ich kenne somit nur den 8051 und den 
68332, und ich finde einfach, beinahe jeder Controller sieht alt aus 
neben dem 68332. ARM usw. kenne ich nicht.

Was meint ihr:
In meinem Schaltplan sollte die BDM-Schaltung korrekt sein, oder? Ich 
habe jetzt von www.oesch.org einen neueren BD32 heruntergeladen 
(NBD32.exe). Der erkennt nun wenigstens, ob die RESET-Line aktiv ist 
oder nicht und ob die CPU angehslten ist.
Wenn ich mir jedoch die Registerinhalte anschaue, dann steht in jedem 
Register: 0000000F. Wenn man das ändern will, dann steht in D0 dann 
0000003F und in allen anderen Registern bleibt das 0000000F erhalten. 
Ein sehr merkwürdiges Verhalten! Übrigens:
Dass TSC auf Masse liegt, das habe ich aus einem anderen Schema 
übernommen. Aber - hat TSC einen Einfluss auf den BDM? Ich hoffe doch 
sehr wohl nicht ;)

Grüsse
     Tobias

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beschaff dir einen PC mit 3stelligen MHz als CPU clock, installiere 
(oder boote) ein einfaches DOS, LPT auf SPP im BIOS und dann sollte es 
so leidlich laufen.

Autor: tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Warum ich den 68332 einsetze: Ganz einfach, in der Firma haben wir auf
>dem das Programmieren gelernt. Ich kenne somit nur den 8051 und den
>68332, und ich finde einfach, beinahe jeder Controller sieht alt aus
>neben dem 68332. ARM usw. kenne ich nicht.
wenn du außer dem 8051 nur den 68332 kennst finde ich eine aussage etwas 
gewagt. das einzige was eine anderen controller alt aussehen läßt ist 
vielleicht noch die TPU des 68332. keine ahnung ob du die nutzen willst 
oder musst. ich wünsch dir viel spaß dabei diese in assembler zu 
programmieren (was anderes gibt es nämlich nicht).
falls du die tpu nicht brauchst dann verschenk den 68332 an ein museum 
und arbeite dich in den arm ein. wenn du tatsächlich schon einige ahnung 
vom 68332 hast dann sollte der arm auch kei problem sein. und was die 
performance betrifft sieht der 68332 ärmlich aus gegen einen arm (ich 
arbeite mit beiden).

und was dein bdm problem betrifft: aus meiner erfahrung funktionieren 
ohnehin nur professionelle lösungen mit dem bdm interface (setze den 
visionice vom windriver ein) und die kosten mehr als die gesamte 
entwicklungsumgebung für den arm. welche tool chain möchtest du den 
einsetzen? und unterstützt der debugger üebrhaupt dein bdm-interface?



gruss
gerhard

Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist leider schon eine Weile her, dass ich etwas mit dem 332 gemacht 
habe, hatte damals einen NF300 mit BDM-Dongle -> 
http://www2.efi.fh-nuernberg.de/labs/mikrocomp/nf3...
Was Du als bdm-Interface auf der Schaltung hast, war damals in einem 
keinen Dongle mit GAL + 244/5? in dem bd32-122.zip ist das orginal 
schematic leider nur als orcad und epson-printer file drinne.
hat eigentlich immer gut funktioniert, allerdings war das noch unter den 
damals modernen BS Win95 und 98.

>>einsetzen? und unterstützt der debugger üebrhaupt dein bdm-interface?
Ist für die grundsätzliche Funktion wahrscheinlich erst einmal 
nebensächlich, solange er mit dem BD32 seinen 68k nicht 'fangen' und 
Register ansprechen kann.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gerhard:
Toolchain? Ich weiss nicht, was du darunter verstehst, aber ich will mit 
dem AS32 (Motorola Freeware Cross Assembler for CPU32) meinen Code 
assemblieren, sodass ich Motorola S-Records erhalte, und diese dann mit 
dem BDM Interface in das RAM runterladen.

@RAY:
Die Schaltung für mein BDM Interface habe ich auf der Website gefunden:
http://www.seattlerobotics.org/encoder/200010/332d...
Das mysteriöse ORCAD-Schema, was in der ZIP-Datei zum BD32 drin ist, 
kann man nicht öffnen. OrCAD meckert: "This is not a valid OrCAD file" 
oder sowas ähnliches.

nochmal @Gerhard:
Hat der Status des TSC-Pins einen Einfluss auf das BDM? Ich finde in 
keinem der Manuals was zu diesem Thema.


Gruss
  Tobias

Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tobias,

ja das Teil ist ziemlich alt, wahrscheinlich zu alt - ich habe leider 
kein Orcad.

Ich habe mir mal die Schaltung von Motorola auf dem link von Dir 
angeschaut: bei Mot geht Reset DSUB-Pin14 auf /CLR und DSUB-Pin17 auf 
/PRE
in deinem Schaltplan geht Reset auf /PRE und DSUB-Pin17 geht auf /CLR 
von deinem FF. Vielleicht liegts da dran.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, dann tausche ich mal die Pins 14 und 17 vom Druckerkabel. Stecker 
öffnen und rasch die Litzen umgelötet, das ist schnell gemacht... Könnte 
es dann klappen?

Ich melde mich auf jeden Fall wieder. Evtl reichts aber heute Abend 
nicht mehr ;)

Gruss & schönen Abend
     Tobias

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@Gerhard:
>Toolchain? Ich weiss nicht, was du darunter verstehst, aber ich will mit
>dem AS32 (Motorola Freeware Cross Assembler for CPU32) meinen Code
>assemblieren, sodass ich Motorola S-Records erhalte, und diese dann mit
>dem BDM Interface in das RAM runterladen.
unter toolchain versteht man allgemein compiler,linker, debugger,..
mal ne frage: was hast du bisher mit dem 68332 gemacht?


>nochmal @Gerhard:
>Hat der Status des TSC-Pins einen Einfluss auf das BDM? Ich finde in
>keinem der Manuals was zu diesem Thema.
ganz schlau werde ich aus dem manuals des 68332 auch nicht. beim 68331 
liegt das signal aber auf 5v.

gruss
gerhard

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gerhard,
Mit dem MC68332 habe ich bisher nur programmiert. Wir haben in der Firma 
ein fertiges Board incl. BDM-Anschluss, und so alte W98-Kistn, auf denen 
das wunderbar läuft. Abr damit du nicht denkst, wir arbeiten mit 
veraltetem Schrott: Das Zug ist natürlich nur für die Auszubildenden 
gedacht, damit die mal die groben Grndzüge der Mikrocomputertechnik 
lernen.
Also meine "Toolchain" setzt sich aus AS32-Assembler und BD32-Debugger 
zusammen. Die kommerzielle Software soll ja angeblich sauteuer sein...

Ich habe gestern Abend noch den Verdrahtungsfehler in meiner 
BDM-Schnittstelle korrigiert. Also Pin17 des Druckerports geht jetzt auf 
/PRE des Flipflops und Pin14 geht auf /RESET des Controllers und auf 
/CLR des Flipflops, genau so, wies sein soll. Funktioniert hat es immer 
noch nicht.... Ich verdächtige nach wie vor Windows. Aber heute habe ich 
Gelegenheit, mal an einem alten DOS-Rechner das auszuprobieren. 
Hoffentlich klappts ;)

Grüsse und einen schönen Tag noch
     Tobias

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so, grade vorhin hatte ich mal mein Board an einen alten '286er 
angeschlossen. BD32 hat sich aufgehängt, wenn man die Register versuchte 
abzufragen... und komischerweise heisst es in der Statusleiste von BD32: 
MCU RUNNING", obwohl das ja nicht möglich ist, wenn der BDM 
eingeschaltet ist.
Langsam verzweifle ich.... Schliesslich war die Leiterplatte nicht 
gratis und auch die anderen ICs die ich einsetze liegen nicht grade 
haufenweise in meiner Bastelkiste rum.
Aber mit dem 68332 möchte ich unbedingt was machen, ARM oder so werde 
ich mich irgendwann mal widmen.
Was meinen die Experten unter euch - gibt es in meinem Schema weitere 
Fehler, die ein nichtfunktionieren der Schaltung erklären könnten?
Langsam glaube ich, könnte auch der Controller defekt sein... Ich habe 
ihn zwar in einer kleinen ESD-sicheren Kartonkiste mit ESD-Schaumgummi 
aufbewahrt, aber beim montieren musste ich ihn zwingendermassen in die 
Finger nehmen, und natürlich habe ich zu Hause keine entsprechenden 
ESD-Schutzmassnahmen...

Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Okay, dann tausche ich mal die Pins 14 und 17 vom Druckerkabel. Stecker
>>öffnen und rasch die Litzen umgelötet, das ist schnell gemacht... Könnte
>>es dann klappen?

Ist fast richtig, da an Pin17 DSUB auch noch das Reset-Signal hängt, 
kannst Du es nicht mehr vom PC aus ansteuern, wenn Du einfach am Stecker 
umverdrahtest -> da Du den Reset brauchst, um den 332 mit dem BDM 'zu 
fangen', wirst Du wohl oder übel auf der LP umverdrahten müssen.

Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups verschaut - an Pin14 der DSUB hängt Reset

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo Ray,
ich weiss-ich habs auch gesehen ;)
also fix die leiterbahnen getrennt und das zeug umverdrahtet...
nun habe ich es nochmal an einer alten DOS-Kiste angeschlossen. siehe da 
- BD32 hängt sich nicht mehr auf. dafür scheint es ein problem mit der 
RESET-Leitung zu geben: in BD32 "flackert" die RESET-Anzeige in der 
Statuszeile und wechselt andauernd zwischen 0 und 1. offenbar scheint es 
da irgend ein problemchen zu geben... Ich werde mal einen anderen 
Quarzoszillator einsetzen, der jetzige scheint mir eh nicht so ein 
tolles Signal auszugeben (laut dem Scope jedenfalls sieht es eher 
sinusmässig aus, und das, obwohl es ein Quarzoszillator für 
Digitalschaltungen ist...).
Gruss
   Tobias

Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tobias,

>>tolles Signal auszugeben (laut dem Scope jedenfalls sieht es eher
>>sinusmässig aus, und das, obwohl es ein Quarzoszillator für
sollte nicht das Problem sein, da wird intern schon ein Rechteck daraus, 
wenn Du einen Quarz anschliesst, dann sieht es auch nicht anders aus.

Hast Du dir die Reset-Leitung angeschaut: wenn da in periodischen 
Abständen jemand an der Reset-Leitung zieht, dann ist das der 332: 
soweit ich mich erinnere, ist nach dem Reset der Software Watchdog aktiv 
-> SYPCR Register. D.h. wenn die CPU nicht angehalten ist (FREEZE fehlt, 
nicht richtig?), läuft der Watchdog Timer ab und macht Dir dann 
automatisch einen Reset.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ray,
ja genau, so ist das. FREEZE bleibt stets auf 0... aber ich denke mir 
mal, wenn ich BKPT/DSCLK auf low halte, während ich einen RESET 
durchfphre, sollte doch der BDM aktiv sein und FREEZE somit auf high = 
5V. Oder täusche ich mich da?
Gruss

Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
leider / Gott-Sei-Dank habe ich mich nie näher mit dem BDM beschäftigen 
müssen, hier ein Ausschnitt aus dem 332 Tutorial - wie es aussieht, muss 
die CPU mit FREEZE=1 antworten, wenn sie in BDM geht:

3.1.2.2 How BDM Works
The debugger causes the MCU to enter debugging mode by driving the BKPT 
pin low at the release of the
RESET signal. Reset causes the MCU to fetch the reset exception vectors, 
load the program counter and
stack pointer, then fetch the first instruction pointed to. Since the 
SRAM module is disabled out of reset,
reset vector fetches are made from external memory enabled by the CSBOOT 
signal. If the CSBOOT chipselect
circuit is configured to enable a 16-bit port (DATA0 = 1 at release of 
RESET), the first word of the
instruction is fetched, however, if the CSBOOT chip-select circuit is 
configured to enable an 8-bit port
(DATA0 held low at the release of RESET), the MCU fetches the first byte 
of the instruction. The MCU then
enters BDM.
At this point the debugger causes the MCU to fetch several instructions, 
which are displayed in the debugger
window on the computer screen. If valid stack pointer and program 
counter values are present, and a
valid program is resident at the address pointed to by the initial PC 
value, the debugger will display the code
beginning at the program counter address.
If the initial stack pointer and program counter values are not valid, 
however, or if the external memory is
either not connected or uninitialized when the fetches are made, it is 
very likely that the initial SP and PC
values will be $FFFFFFF. CSBOOT is the only chip-select circuit that is 
active out of reset, and it enables
only the first 1 Mbyte of memory — when the first instruction fetches 
are made at $FFFFFF, there will be
nothing to generate DSACK and terminate the bus cycle, and the debugger 
software will force a bus error.
Should this occur, the debugger generally displays a series of “Memory 
implementation error: debugger
supplied DSACK” messages on the computer screen. After the debugger 
software has finished making the
scheduled number of program fetches, the error messages will stop, and 
the MCU will be in BDM waiting
for the next debugger command. However, additional errors will occur if 
the next command is an external
memory access because the program counter and stack pointer values are 
invalid.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo RAY,
ja das habe ich gemeint. FREEZE muss 5V führen, wenn der BDM aktiv ist.
BDM kann man ja nur dadurch aktivieren, dass BKPT/DSCLK low ist, während 
ein RESET durchgeführt wird, aber nachdem der RESET ausgeführt wurde, 
muss ja BKPT wieder HIGH sein, denn im Manual heisst es irgendwie sowas:

If BKPT/DSCLK is held low during normal processing, the current bus 
cycle is tagged with a breakpoint.

Muss ich jetzt BKPT gleichzeitig mit RESET auf high legen, oder noch 
eine gewisse Zeit lang auf LOW halten, während RESET auf high geht?

Gruss
      Tobias

Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
hier nochmal ein Zitat aus den Motorola Unterlagen (CPU32 Reference 
Manual):

BDM operation is enabled when BKPT is asserted (low), at the rising edge 
of RESET. BDM remains enabled until the next system reset. A high BKPT 
signal on the trailing edge of RESET disables BDM. BKPT is relatched on 
each rising transition of RESET.
BKPT is synchronized internally, and must be held low for at least two 
clock cycles prior to negation of RESET.
BDM enable logic must be designed with special care. If hold time on 
BKPT extends into the first bus cycle following reset, the bus cycle 
could inadvertently be tagged with a breakpoint. Refer to the system 
integration module user's manual for timing information.

Ausserdem:

Once enabled, BDM is initiated whenever assertion of BKPT is 
acknowledged.

d.h. sobald der BDM aktiviert wurde, musst Du nur nBKPT auf Masse ziehen 
und die 332 solte mit FREEZE=1 antworten:

and asserts the FREEZE output. This is
the first indication that the processor has entered BDM. Once FREEZE has 
been asserted, the CPU enables the serial communication hardware and 
awaits a command.

Allerdings müsste das eigentlich der BD32 erledigen

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo RAY,
danke für die Auskunft. Mir ist aber eins nicht klar:

>>If hold time on BKPT extends into the first bus cycle following reset, the bus 
cycle could inadvertently be tagged with a breakpoint. Refer to the system 
integration module user's manual for timing information.

Was heisst das? Wenn ich BKPT zu lange auf low halte, nachdem /RESET 
negiert wurde, wird der nächste Buszyklus als Breakpoint angesehen und 
die Breakpoint exception aufgerufen? Und da die CPU den Vektor nicht 
findet (im RAM befindet sich ja noch nichts), tritt in double bus fault 
auf und der Prozessor sollte anhalten? Oder wie muss ich mir das 
vorstellen wenn ein bus cycle als breakpoint tagged ist?

Gruss & schönen Abend
  Tobias

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für alle die es interessiert:
Hurra, mein Board funzt!
Es war kein Layoutfehler, und auch die sonstige Beschaltung des 68332 
stimmt. Nur: Nach dem RESET versuchte der Prozessor, auf das nicht 
initialisierte RAM zuzugreifen. Was natürlich fehlschlug, weil ja keine 
Daten drin stehen... Zitat aus dem 68332 Tutorial von Freescale:

The memory is uninitialized, and the processor is trying to access bad 
addresses. In this case, most debuggers should drive BERR to terminate 
the bus cycle. If the debugger does not do this, either write valid 
addresses to the reset vectors or, if this is not possible, manually 
pulse BERR low to terminate a hung bus cycle.

Ich habe nur BERR auf low gelegt (von Hand), danach hats geklappt. Ich 
kann Register ändern, anschauen, Programmme runterladen...
Nur eins geht nicht:
Grad nach dem RESET kann man einfach nicht auf das RAM zugreifen (weder 
lesen, noch schreiben). Warum ist mir unerklärlich.

Grüsse
  Tobias

Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tobias,

schön, dass es läuft, um auf deine Peripherie (in deinem Fall nur RAM) 
zugreifen zu können, musst Du erst einmal dein System Integration Module 
(SIM) konfigurieren, damit es weis, welches CS zu deinem Speicher 
gehört.

Hier ein Beispiel für eine Ini-Datei für den alten NF300:

* Switch off software watchdog, enable busmonitor
mm $fffa20
$c.
* enable busmonitor during freeze
mm $fffa00
$40cf.
* set up chip selects
* CSBOOT for read only
* CS0 for write only
mm $fffa48
$5
$6830
$1003
$6830
$1003
$3030
$1003
$5030
$5
$3030
$5
$5030.
* tell BD32 to use internal RAM $100000 for target resident driver
driver $100000

Also 0xfffa20 <- 0x000c (SYPCR)
     0xfffa00 <- 0x40cf (SIMCR)
     0xfffa48 <- 0x0005 (CSBARBT)
     0xfffa4a <- 0x6830 (CSORBT)
etc.

Für dein RAM musst Du nun entsprechend die Register (CS Assignment und 
Option Register) initialisieren, damit Du deine daran angeschlossenen 
Bausteine auch ansprechen kannst.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo RAY,
Ja das habe ich auch getan - allerdings von Hand. Der Witz dabei sollte 
ja eigentlich sein, dass mit meiner Beschaltung der Prozessor eigentlich 
aus dem RESET heraus das RAM wenigstens lesen können sollte.
Ich habe mir das folgendermassen gedacht:

CSBOOT aktiviert jeweils das RAM mit CS.
RW invertiert wird auf OE des RAMs geführt, so sollte eigentlich ein 
Speicher-Lesen-Zyklus durchgeführt werden, wenn RW auf high geht. Das 
scheint jedoch nicht zu klappen:

Wenn ich dem RAM gültigen Code und die richtigen Vektoren 
einprogrammiere, dann kann er nach dem RESET nichts vom RAM lesen, er 
bekommt nur 0. Das finde ich höchst eigenartig; denn eigentlich sollte 
CSBOOT ja auf low gehen, RW auf high, und das RAM sollte gelesen werden. 
Die Vektoren übernimmt er aber komischerweise überhaupt nicht :(

Wie du aus dem Schema vielleicht noch weisst, habe ich das RAM als 
NF-RAM konzipiert. Der Inhalt bleibt also auch beim Ausschalten und über 
den RESET hinweg erhalten. Nun habe ich für initial SSP und initial PC 
die richtigen Vektoren eingetragen, ein Programmm an der entsprechenden 
Adresse im RAM gespeichert, und RESET gedrückt. Eigentlich sollte der 
Prozessor sich ja jetzt die Vektoren holen, tut er aber leider nicht. 
(Darf man RW invertiert überhaupt auf OE des RAMs führen? Ich habe RW 
noch mit einem 10k Pullup versehen, wie es Motorola vorschreibt).

Danke trotzdem für das Initscript.

Grüsse
   Tobias

Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tobias,

wenn ich es recht gesehen habe, ist nCSBOOT nach dem Reset 16bit breit, 
alle anderen CS-Signale ausgeschaltet. D.h. für deine Schreibzugriffe 
musst Du auf jeden Fall die CS definieren und deine 16-Bit Worte über 
zwei 8bit Zugriffe schreiben bzw die beiden CS-Signale so definieren, 
dass das eine das LoByte, das andere das HighByte anspricht.

Ich kenne das verwendete RAM jetzt nicht, aber schau mal ins Datenblatt, 
meistens gibt es die Möglichkeit, /OE fest auf GND zu schalten, dann 
kannst Du direkt mit R/W auf /WE gehen. Mit (einem) /CS kannst Du dann 
lesen, mit /CS+/W schreiben.

Hast Du ein Oszi mit single Trigger und geschaut, ob die CS-Signale auch 
wackeln, wenn Du versucht zu lesen bzw. schreiben?

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo RAY,
ein Oszi habe ich leider nicht :p Die sind viel zu teuer, und ich denke 
extra für so Hobby-Bastelarbeiten lohnt sich die Anschaffung nicht. Oder 
täusche ich mich?

Übrigens:
Du hast recht; /CSBOOT ist 16 Bit breit. Nun: Nach dem RESET sollte 
CSBOOT ja auf low gehen. Tut es auch korrekt. Die RAM-Bausteine sind 
also aktiviert. Und nun will der Prozessor ja den Resetvektor holen, 
also muss er doch RW auf high setzen, und dank dem Inverter, den ich mit 
RW verbunden habe, sollte das  RAM an /OE auch low sehen und somit die 
gewünschten Daten ausgeben. Das klappt aber nicht :( Wenn ich von Hand 
die CS-Signale korrekt einstelle, funktioniert alles, aber halt aus dem 
RESET heraus nicht.

Übrigens:
Ich habe noch folgendes rausgefunden (sehr merkwürdig):
Stellt man CSORBT (Chip select boot option register) auf den Hex-Wert 
$7B70 (nach dem RESET), sind die RAM-Bausteine nicht lesbar ($7B70 = 13 
Wait States). Stelle ich jedoch von hand nach $7BB0 oder $7870 um (Fast 
Termination bzw. 1 Wait State), dann klappt alles. Hast du auch dafür 
eine Erklärung bereit? :D

Mann, ich hätte nie gedacht, dass der MC68332 auch so kompliziert sein 
kann. Eigentlich schaut das Businterface recht simpel aus... ;)

Grüsse und einen schönen Tag noch
   Tobias

Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tobias,

dafür, dass es mit einem WS funktioniert, mit 13 nicht, habe ich erst 
mal auch keine Erklärung. Mir ist jetzt allerdings noch aufgefallen, 
dass Du an einigen Signalen keine Pull-Ups hast, bei denen Motorola 
damals welche vorgesclagen hat - Auszug aus dem Tutorial:

2.3 Pins that Need Pull-Up Resistors
Many of the input pins need pull-up resistors to prevent unexpected 
conditions. The pins discussed below must be conditioned in all 
applications. An incorrect voltage on one or more of them can cause 
general system failure. Other input pins, such as TPU inputs, can be 
left floating without adverse effect in certain applications.
The designer must determine which pins can cause system failure in a 
particular application and deal with them appropriately. In general, it 
is best to condition all input pins so that they are in a known state,
whether they are used or not.

BR/CS0
BERR
HALT
IRQ[1:7]
DSACK[0:1]
AVEC
TSTME/TSC
BKPT/DSCLK
R/W
RESET

MODCLK — If using the internal PLL to generate the system clock, this 
pin must be pulled up with a 10KW resistor or driven high during reset. 
If using an external clock source and bypassing the PLL, connect
this pin to ground or drive it low during reset.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo RAY,
ja an einigen Signalen habe ich keine Pullups.
Aber:
An den Port E-Pins und Port F-Pins brauchts keine, weil ich dort nämlich 
mittels der Dioden/Widerstände an DATA3,8 und 9 dafür sorge, dass es 
nicht Bussteuersignale sind, sondern ganz normale Portpins. Deshalb 
brauchts da laut 332 Tutorial auch keine Pullups. Wären es 
Bussteuersignale, dann hast du recht. MODCLK habe ich auf der LP mit GND 
verbunden, das sollte passen... der Controller läuft ja eigentlich. Nur 
nicht ganz so wie man sich das vorstellt ;)


Grüsse & schönen Tag
      Tobias

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@RAY:
nochaml ne Frage.
Ich bin am Entwickeln eines neuen Boards...
Das schon bald fertig ist. Bevor ich aber diesmal die Leiterplatte 
mache, möchte ich ganz sicher gehen, dass meine Überlegungen richtig 
sind... Könnte ich nicht dir mal mein Schema zusenden und du schaust es 
dir an? Du scheinst eine Art Experte auf 68332 zu sein; deshalb wäre ich 
sehr froh ;) Denn im Internet findet man zu dem Prozessor viele Sachen, 
aber oft halt schlecht dokumentiert etc.

Würde mich sehr freuen!

Grüsse
    Tobias

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.