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.
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.
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?
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
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
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.
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
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.
>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
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/nf300/tools/tools.htm 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.
@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/332designs/const332.htm 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
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.
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
>@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
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
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...
>>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.
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
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.
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
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.
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
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
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
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
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.
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
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?
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
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.
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
@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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.