Hallo zusammen, 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. Grüße Steffen
Angehängte Dateien:
-
CS_Verdrahtung_CPU32.png
56 KB
:
Bearbeitet durch User
Hat jemand das Know How und kann mir weiterhelfen? Steffen
Hallo, 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. Gruß aus Berlin Michael
Es würde helfen, zu wissen, welchen Flash-Baustein Du konkret vor Dir hast, aber vielleicht hilft ja | https://datasheetspdf.com/pdf-file/706150/STMicroelectronics/M28F102/1 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. HTH (re)
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
CS_logic.png
2,8 KB
So könnte es funktionieren. Dmit bekommst du aus RW !OE und !WE aufgetrennt. Beim RAM gibts das Problem ja auch da kannst du dann den zweiten Dekoder verwenden.
:
Bearbeitet durch User
Michael U. schrieb: > 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. Re schrieb: > Es würde helfen, zu wissen, welchen Flash-Baustein Du konkret vor Dir > hast Ich möchte einen Am29F100 verwenden. Motopick schrieb: > Der "vermeintliche" Fehler ist wohl eher anzunehmen, dass die > CPU ueberhaupt in diesen Flash schreibt oder schreiben koennte. Dann hätte ich erwartet, dass /WE fest auf high verdrahtet wäre. Aber es stimmt schon, das kann natürlich auch der Hintergrund sein. Thomas Z. schrieb: > 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 :-)
:
Bearbeitet durch User
Steffen H. schrieb: > Ist das erprobt? 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)
Steffen H. schrieb: > Ich möchte einen Am29F100 verwenden. Dann sagt das das Datenblatt | https://www.physi.uni-heidelberg.de/~angelov/g2/MP042_Controller_68332/MP42-AM29F100.PDF 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. HTH (re)
:
Bearbeitet durch User
> 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.
Motopick schrieb: > Mit nur einem Flash im System, wirst du auf Probleme stossen, > wenn du den im Betrieb beschreiben willst. Das System hat ja auch noch RAM, wenn ich das richtig sehe.
Motopick schrieb: > 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?
Motopick schrieb: > 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.
Angehängte Dateien:
-
CPU-RAM-FLASH.png
120 KB
Motopick schrieb: > Ich habe von Winzsystemen mit dem 68302 abgesehen, bislang nur > die Zweiteilung in Boot-ROM und Flash gesehen. Dann zeige ich Dir eine Schaltung, wie es Mitte der 90er schon funktioniert hatte (seinerzeit noch mit H8/3002 bzw. 68HC001).
> Dann zeige ich Dir eine Schaltung
Ja, sehr hypsch.
Ich kann und darf leider keine Schaltung zeigen, weil die
in einem ASIC "verschwunden" ist. War an einem 68360.
Motopick schrieb: > 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.
> Da sieht man den Unterschied
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 :).
Motopick schrieb: > 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?
Re schrieb: > Dann sagt das das Datenblatt > > | > https://www.physi.uni-heidelberg.de/~angelov/g2/MP042_Controller_68332/MP42-AM29F100.PDF > > 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. Link: https://pdf1.alldatasheet.com/datasheet-pdf/view/55463/AMD/AM29F100.html Re schrieb: > 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. Motopick schrieb: > Besonders schnell wird das mit den byteweisen Zugriffen auch nicht. Danke für den Hinweis. Ich verwende Wortbreite. Das ist zwar immer noch nicht schnell, aber ich komme zurecht. Mi N. schrieb: > 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 oder den vorgeschlagenen Dekoder von usbman? Mi N. schrieb: > Was für den TO eine zeitgemäße Dekodierung wäre, hast Du übrigens noch > nicht verraten. ASIC mit 5V Pegelwandlern? Ich brauche eine Lösung, die funktioniert ;-) Wenn es einen Dekoder mit mehr Vorteilen gibt - klar, gerne! Aber zeitgemäß ist für mich unwichtig. Vielen Dank für Eure Hilfe! Steffen
> Und, was war das Ziel der Übung? 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.
Steffen H. schrieb: > Mi N. schrieb: >> 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.
Steffen H. schrieb: > 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. https://pdf1.alldatasheet.com/datasheet-pdf/view/7960/NSC/74F139.html (re)
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.