im Datenblatt zu meiner CPU32 (MC68336) wird folgender Aufbau im Anhang vorgeschlagen. Was haltet ihr davon?
Aus meiner Sicht ist dort ein Fehler: Der /CSBOOT Ausgang (Chip Select aktiv beim Aufstart) ist sowohl mit /CE als auch mit /OE des FLASHs verbunden. Dadurch kann sich der Prozessor beim Aufstart natürlich den Code aus dem FLASH holen. Aber gleichzeitig wird ein Überschreiben des FLASHs unmöglich gemacht! Denn dafür müssen /CE = aktiv, /OE = inaktiv und /WE = aktiv sein - was sich mit dem Aufbau nicht einstellen lässt.
Übersehe ich da etwas? Falls es ein Fehler ist - wie verdrahtet man das richtig? Das Problem ist ja grundsätzlicher Natur: beim Aufstart müssen /CE und /OE gleichzeitig aktiv werden und um das zu Erreichen steht nur /CSBOOT zur Verfügung.
das sagt Dir das Datenblatt des konkreten Flashs.
Ich kenne es von früher z.B. von RAM oder EPROM, daß /WE die höhere Priorität hat. Bei /WE = low sind die Datenleitungen immer Eingang, egal ob /OE aktiv gesetzt ist.
Würde mich wundern, wenn das bei Flash anders wäre.
Table-3 weiter. In Figures 8 bis 10 sind die Timings für "Write" angegeben.
Da muss zum Schreiben /E (=/CS) immer LOW sein und /G (=/OE) immer HIGH.
Und außerdem muss Vpp angesteuert werden. Beides ist in Deinem Schaltplan nicht vorgesehen.
Bei den "gereiften" RAMs und EPROMs wurde im Datenblatt ja auch noch ausdrücklich erwähnt, dass /OE zum Schreiben egal ist - bei diesem Flash wird das aber afaik nicht garantiert.
Wenn Du einen anderen Flash-Typ vor Dir hast, mag das anders aussehen.
Der "vermeintliche" Fehler ist wohl eher anzunehmen, dass die
CPU ueberhaupt in diesen Flash schreibt oder schreiben koennte.
Ich habe hier "Rechner" mit dem 68360. Die haben zwei Flashbereiche.
Einen, byteorientiert, als Bootrom und einen zweiten, 32 Bit breit,
der auch schreibbar ist.
das sagt Dir das Datenblatt des konkreten Flashs.
Ich kenne es von früher z.B. von RAM oder EPROM, daß /WE die höhere
Priorität hat. Bei /WE = low sind die Datenleitungen immer Eingang, egal
ob /OE aktiv gesetzt ist.
Ah okay. Ich dachte, /OE aktiviert stumpf die Ausgangstreiber. Und dass das im JEDEC Standard(?) so festgelegt ist und deshalb bei nahezu allen FLASH gleich wäre.
So könnte es funktionieren. Dmit bekommst du aus RW !OE und !WE
aufgetrennt.
Stark, danke für den Tipp! Von der Logik her passt das prima. Ist das evtl. sogar von Dir erprobt? Ich muss mal schauen, ob das vom Timing her bei mir funktioniert :-)
nicht mit deiner CPU aber in ähnlichen Fällen hab die 139er schon oft so benutzt. HC(T) wird in deinem Fall etwas zu langsam sein, aber AHC(T) sollte es tun. (typisch 15ns)
doch recht eindeutig auf Seite 1-39, dass /CE = /OE = LOW zu in jedem Fall zu einem Read-Zugriff führt. Sagt Dein Datenblatt etwas anderes?
Thomas Z. schrieb:
So könnte es funktionieren.
Ist das evtl. sogar von Dir erprobt?
Das ist eigentlich eine Standardschaltung; Vor Jahr und Tag hatte ich sowas auch an einem 68332 (Gott hab ihn selig) in einer dreistelligen Kleinstserie drangehabt.
Moderne 74er-Serien gibt es aber sowieso mit nur wenigen ns Delay, wird also kein Problem geben.
Für alles andere als Boot ist das ohnehin problemlos, weil das Timing ja per Register beeinflussbar ist.
Aber wozu eigentlich? Typischerweise ist das BOOT-(EEP)ROM klein, 8-Bittig und quasi in Stein gemeißelt und nur der Application-Flash wird bei Bedarf neu geschrieben. Alles andere führt dazu, dass Du bei einem Fehler während des Flashens das System nicht mehr gebootet bekommst.
Das ist eigentlich eine Standardschaltung; Vor Jahr und Tag hatte ich
sowas auch an einem 68332
Da vermutlich noch Peripherie dazu kommt, tu dir einen Gefallen
und benutze etwas heute angemesseneres zum dekodieren.
Selbst GAL war schon vorgestern und CPLDs kommen auch schon in
die Jahre.
Die haben zwei Flashbereiche. Einen, byteorientiert, als Bootrom
und einen zweiten, 32 Bit breit, der auch schreibbar ist.
Typischerweise ist das BOOT-(EEP)ROM klein,
8-Bittig und quasi in Stein gemeißelt und nur der Application-Flash wird
bei Bedarf neu geschrieben.
Mit nur einem Flash im System, wirst du auf Probleme stossen,
wenn du den im Betrieb beschreiben willst.
Besonders schnell wird das mit den byteweisen Zugriffen auch nicht.
Da vermutlich noch Peripherie dazu kommt, tu dir einen Gefallen
und benutze etwas heute angemesseneres zum dekodieren.
Selbst GAL war schon vorgestern und CPLDs kommen auch schon in
die Jahre.
Na, was ist denn heute angemessen?
74HCT139 habe ich auch noch in der Kiste. Schönes Teil, um R/W in die Form /RD und /WR zu bringen und noch weitere /CS zu erhalten.
Aber die obige Schaltung würde ich vor dem Nachbau zunächst funktionfähig aufzeichnen. Da stimmt Einiges nicht.
Erzeugt der gezeigte MC68k /DTACK für die Peripherie bereits intern oder muß man noch ein 74HCT164 ergänzen?
Da vermutlich noch Peripherie dazu kommt, tu dir einen Gefallen
und benutze etwas heute angemesseneres zum dekodieren.
Selbst GAL war schon vorgestern und CPLDs kommen auch schon in
die Jahre.
ja eben weil Gals und CPLDs ziemlich obsolet sind und das ein 5V Design ist, ist doch ein Decoder mit TTL gar keine schlechte Wahl.
Das Flashen ist kein Problem, man muss halt die Flashroutinen ins Ram kopieren und von dort starten. Die einzige Gefahr besteht darin, dass man während des Flashens das System kaputt machen kann. Das kann man aber schon hinbekommen wenn man einen Sektor schreibschützt und nur Sektorerase verwendet.
Das System hat ja auch noch RAM, wenn ich das richtig sehe.
Ich kenne den MC68336 zu wenig, um ganz sicher sagen zu koennen,
dass es reicht die Programmteile zum Flashen dann im RAM vorzuhalten.
Ich denke da z.B. an Interrupte und aehnliche Stoerquellen :).
Es schadet sicher nicht, den TO darauf hinzuweisen.
Ich habe von Winzsystemen mit dem 68302 abgesehen, bislang nur
die Zweiteilung in Boot-ROM und Flash gesehen.
Ich kann und darf leider keine Schaltung zeigen, weil die
in einem ASIC "verschwunden" ist. War an einem 68360.
Da sieht man den Unterschied zwischen Herr und Knecht. Ich darf Dir alles erzählen ;-)
Das Startup-Programm liegt im FLASH 0x0 - 0x3fff und programmiert sich die /CS-Leitungen so um, daß anschließend das RAM ab 0x0 liegt und das auszuführende Programm im Flash so ab 0x804000 (typisch 1/2 Adressbereich). Startup wartet ca. 0,5 s auf Befehle per RS232 und springt ansonsten ins Hauptprogramm.
Wird ein "Kennwort" empfangen, kann der Bootloader im Flash ein Programm ins RAM schreiben und starten. Erst dieses Programm enthält Routinen zum Programmieren des Flash. Das Flashprogramm kann sich somit nicht selber "zerschiessen".
Das RAM war neben der Uhr auch noch batteriegepuffert. Im Prinzip hat es ausgereicht, das eigentliche Programm nur ins RAM zu laden und dort laufen zu lassen. Das war für die Entwicklung etwas schneller als erneutes Beschreiben des Flash.
Nun ja, ich moechte dafuer mal wetten, dass du noch keinen ASIC
versenkt hast. Das ist fuer den "Herrn" naemlich ganz schoen teuer.
Im uebrigen ist auch keiner mehr ueber mir.
Bei meinem zweiten Z80-Rechner:
Das Startup-Programm liegt im EPROM 0x0 - 0x3ff und programmiert
sich die /CS-Leitungen so um, daß anschließend das RAM ab 0x0 liegt.
Das ist also auch nicht gerade neu :).
Das Startup-Programm liegt im EPROM 0x0 - 0x3ff und programmiert
sich die /CS-Leitungen so um, daß anschließend das RAM ab 0x0 liegt.
Das ist also auch nicht gerade neu :).
Und, was war das Ziel der Übung? Hast Du ihn dann per PC per DFÜ umprogrammiert?
Beim M68k konnte man sich damit zur Laufzeit die Vektoren umprogrammieren, was viele Leute dann auf die Palme brachte. Da wurde argumentiert, sie könnten ja zerschossen werden und das Programm zum Absturz bringen.
Aber die selben Leute haben den Stack im RAM liegen lassen ;-)
Was für den TO eine zeitgemäße Dekodierung wäre, hast Du übrigens noch nicht verraten. ASIC mit 5V Pegelwandlern?
doch recht eindeutig auf Seite 1-39, dass /CE = /OE = LOW zu in jedem
Fall zu einem Read-Zugriff führt. Sagt Dein Datenblatt etwas anderes?
Das ist interessant! Dein Datenblatt ist Revision B (November 1995). Meines ist Revision C (März 1998) und darin steht in Table 1, dass /WE auf "H" liegen muss.
Aber wozu eigentlich? Typischerweise ist das BOOT-(EEP)ROM klein,
8-Bittig und quasi in Stein gemeißelt und nur der Application-Flash wird
bei Bedarf neu geschrieben. Alles andere führt dazu, dass Du bei einem
Fehler während des Flashens das System nicht mehr gebootet bekommst.
Wie später im Thread beschrieben, wird mein Bootloader in einem schreibgeschütztem Sektor liegen. Die Programmier-Routinen lade ich ins RAM. Dieser Aufbau ist bereits grob vorgegeben. Ich möchte ihn lediglich für Messzwecke erweitern und dabei nicht zu viel umbauen.
Man konnte ihn ueber ein gleichspannungsfreies synchrones
Datenprotokoll booten. Z.B. von einem Tape.
Das erste Band wurde von meinem ersten Z80-Rechner per
Monitor erstellt. Auf dem Band war ein Monitorprogramm fuer den
zweiten Z80 Rechner...
Spaeter kamen dann noch ein Basic, CP/M, ...
Hast Du ihn dann per PC per DFÜ umprogrammiert?
"Den" PC gab es zu dieser Zeit bei mir nicht.
Aber er bekam spaeter seinen Code auch von einem C64.
Und noch ein wenig spaeter von einem C128D.
Was für den TO eine zeitgemäße Dekodierung wäre...
Dafuer war der TO mit Informationen zum gesamten System viel
zu sparsam. In seinem ersten Beitrag war ein "Minimalsystem"
dargestellt.
Ich persoenlich wuerde wohl zu ispLSI1016 und Abkoemmlingen greifen
wenn es etwas komplexer wird.
Wenn der Aufwand der Dekodierung ueberschaubar bleibt,
kann der TO ja machen was er will :).
Mache ich ja auch.
Aber die obige Schaltung würde ich vor dem Nachbau zunächst
funktionfähig aufzeichnen. Da stimmt Einiges nicht.
Meinst Du die Schaltung aus dem Datenblatt
Die aus dem Datenblatt. Vergleiche doch einfach einmal die obige Funktionszeichnung und die realen Anschlüsse am Flash.
Ich brauche eine Lösung, die funktioniert ;-)
Da frage ich mich, warum Du gerade diesen Controller verwenden möchtest. So schön die Schaltung mit ihm auch sein möge, sie hat keinen praktischen Nutzen mehr. Er hatte seine Zeit, aber die ist vorbei.
Meines ist Revision C (März 1998) und darin steht in Table 1, dass /WE
auf "H" liegen muss.
Huch? Tatsächlich, das Verhalten für /WE = /CE = /OE = "LOW" ist in der neueren Revision C gar mehr definiert. However, ein garantiertes "Write" wird das in keinem der beiden Fälle.
Der Schaltungsvorschlag aus dem Datenblatt setzt den typischen Fall voraus, dass das BOOT-ROM niemals überschrieben werden soll. Bei Dir soll das anders sein, also passt der 08/15-Vorschlag des DB nicht mehr. Aus meiner Sicht kein Fehler im DB, sondern nur andere Voraussetzungen.
Die Lösung von Thomas Z. mit 74139 ist jedenfalls jahrzehntelang bewährt, wenn dadurch das Timing-Budget nennenswert strapaziert wird, nimmt man eben die F-Serie.
CS_Verdrahtung_CPU32.png
(56 KB)
