Hallo,
ich nutze einen AT89C51RC2 (32k Flash) mit externem RAM (64k). Unterhalb
von 8000H erfolgt der Zugriff jeweils getrennt zwischen internem Flash
und externem RAM. Da der µC nur 32k Flash hat, sorgt die Beschaltung
(/RD und /PSEN durch UND verknüpft) dafür, dass auf dem oberen
RAM-Speicher (8000H-EFFFH) gemeinsam mit MOVC und MOVX zugegriffen
werden kann. Dies funktioniert auch bis hier her.
Beispiel:
a) C:7500H 22H (RET)
b) C:C000H 22H (RET)
b) X:C000H 22H (RET)
Im Fall a) kann nur mit dem MOVC-Befehl zugegriffen werden.
Im Fall b) kann mit dem MOVC- und MOVX-Befehl zugegriffen werden.
Wird nun der Befehl LCALL 7500H ausgeführt, so erfolgt erwartungsgemäß
auch der direkte Rücksprung.
Wird aber der Befehl LCALL 0C000H ausgeführt, so wird ein Reset
ausgelöst!
Wieso ist das so, wurde hier ggf. vergessen ein Register zu setzen?
Ich habe das Teil noch nie in der Hand gehabt, aber eben einfach mal ins
Datenblatt gesehen:
https://ww1.microchip.com/downloads/en/DeviceDoc/doc4180.pdf
In Tabelle 66 auf Seite 88 steht unter Security Level 4 "external
execution is disabled. (Default)". Das hat mir zu denken gegeben. Kann
es damit zusammenhängen?
ist zwar keine Antwort auf dein Problem. Der Rücksprung sollte auch bei
0xC000 funktionieren. Allerdings ist dein Adressdecoder seltsam:
Ist es beabsichtigt dass du ab F000 das RAM inaktiv schaltest?
René K. schrieb:> In Tabelle 66 auf Seite 88 steht unter Security Level 4 "external> execution is disabled. (Default)". Das hat mir zu denken gegeben. Kann> es damit zusammenhängen?
Da habe ich auch schon daran gedacht. Daher habe ich den µC komplett
gelöscht und über den UART neu programmiert. Ich kann mit MOVC im oberen
Bereich vom RAM zugreifen, nur komischer Weise keinen Code ausführen.
Im Bild von Atmel-Flip ist wohl Level 0 gesetzt, aber das war auch nach
dem Löschen schon so. Wahrscheinlich ist es ein Fehler in der
Darstellung, da Security Level auf FF steht und man mit MOVC Zugriff
hat.
Thomas Z. schrieb:> Allerdings ist dein Adressdecoder seltsam:> Ist es beabsichtigt dass du ab F000 das RAM inaktiv schaltest?
Das ist korrekt, da der Bereich (F000H-FFFFH) für I/O-Anwendungen
benutzt wird. Da es keine Auswirkung auf das beschriebene Problem hat,
habe ich daher diesen Teil weggelassen.
Werner M. schrieb:> Daher habe ich den µC komplett> gelöscht und über den UART neu programmiert.
Wie gelöscht? Ich frage, weil: "Hardware registers can only be accessed
through the parallel programming modes which are handled by the parallel
programmer."
Werner M. schrieb:> Ich kann mit MOVC im oberen> Bereich vom RAM zugreifen, nur komischer Weise keinen Code ausführen.
So wie ich das verstehe, ist das auch im Security Level 4 in Ordnung, da
Dein MOVC aus dem FLASH heraus ausgeführt wird.
René K. schrieb:> So wie ich das verstehe, ist das auch im Security Level 4 in Ordnung, da> Dein MOVC aus dem FLASH heraus ausgeführt wird.
Von der Seite habe ich es bisher noch nicht betrachtet!
Ich bin davon ausgegangen, dass mit der kompletten Löschung auch die
Security Bits gelöscht werden. Für meinen alten SuperPro 2 bräuchte ich
erst einmal einen Adapter für PLCC44 und dann ist es fraglich, ob der
AT89C51RC2 mit den 89C51 von Atmel programmiert werden kann.
Oder gibt es eine andere einfache Methode den µC parallel zu
programmieren?
Werner M. schrieb:> Im Bild von Atmel-Flip ist wohl Level 0 gesetzt, aber das war auch nach> dem Löschen schon so. Wahrscheinlich ist es ein Fehler in der> Darstellung, da Security Level auf FF steht und man mit MOVC Zugriff> hat.
nein das ist schon richtig so, die Security Bits sind unprogrammiert und
damit 1. Der Controller isst also komplett offen.
Kannst du mal dein Testprogramm zeigen?
Bist du sicher dass bei den Adressen A12-A15 nicht irgendwo ein Schluss
ist?
Meine Vermutung wäre dass durch einen Schluss nicht C000 sondern F000
angesprungen wird, dort ist ab nichts der Controller macht nop oder MOV
A,R7 bis die Adresse überläuft.
Thomas Z. schrieb:> nein das ist schon richtig so, die Security Bits sind unprogrammiert
Laut Datenblatt ist aber Level 4 der default Level. Dann funktioniert
zwar MOVC aber keine Programmausführung im High Memory.
Bei einem Schluss auf dem Adressbus würden MOVX und MOVC auch nicht
funktionieren.
Georg G. schrieb:> Laut Datenblatt ist aber Level 4 der default Level. Dann funktioniert> zwar MOVC aber keine Programmausführung im High Memory.
Da ist das Datenblatt m.M. nicht ganz eindeutig. Sie schreiben zwar
default
sagen aber auch dass die Bits unprogrammiert sind und damit 1.
FF ist nach meinem Verständnis komplett offen -> Level 0.
Atmel hatte aber schon immer so diverse Probleme die Bits korrekt in den
DBs zu beschreiben.
> Bei einem Schluss auf dem Adressbus würden MOVX und MOVC auch nicht> funktionieren.
Das stimmt da hab ich zu kurz gedacht.
Thomas Z. schrieb:> Da ist das Datenblatt m.M. nicht ganz eindeutig.
Ich denke doch:
The only hardware register of the AT89C51RB2/RC2 is called Hardware
Security Byte (HSB).
Hardware registers can only be accessed through the parallel programming
modes which are handled by the parallel programmer.
Ein "Parallel Programmer" wurde hier aber nicht verwendet.
Der oben im Screenshot gezeigte Security Level geht nur 0..2, das reicht
nicht für das Hardware Security Byte, das hätte 1..4 sein müssen.
Allerdings langt das für das Software Security Byte (User Memory Lock
Bits, Tabelle 68, Seite 89)). Das ist was anderes.
Thomas Z. schrieb:> Kannst du mal dein Testprogramm zeigen?
Ich nutze den Code vom 8052AH BASIC, dort wird definitiv mit den
Befehlen CBY und DBY aus dem Flash mit MOVC (bedingt durch die Hardware)
und MOVX auf das externe RAM zugegriffen.
Ein Kurzschluss oder Unterbrechung schließe ich aus, da ich mit 2
Platinen (unterschiedlicher Versionsstand) dieses Problem überprüft
habe. Auch wenn ich einen AT89C51RD2 (64k) verwende, wird mit MOVC auch
nur der Flashinhalt angezeigt. Zugriff auf das RAM geht in diesem Fall
nur über MOVX. Somit kann ich ein Softwarefehler ausschließen.
Die Frage ist hier, ob vielleicht doch ein Bit vom Security Level
gesetzt ist. Oder gibt es noch ein Register, womit die externe
Programmausführung gesperrt werden kann. Dann wäre das Problem logisch
und nachvollziehbar.
Georg G. schrieb:> Laut Datenblatt ist aber Level 4 der default Level. Dann funktioniert> zwar MOVC aber keine Programmausführung im High Memory.
Dann müsste aber Level2 markiert sein, was laut Bild nicht der Fall ist.
Welchen Sinn sollte es haben, das ein neuer Controller gesperrt ist?
René K. schrieb:> Der oben im Screenshot gezeigte Security Level geht nur 0..2, das reicht> nicht für das Hardware Security Byte, das hätte 1..4 sein müssen.> Allerdings langt das für das Software Security Byte (User Memory Lock> Bits, Tabelle 68, Seite 89)). Das ist was anderes.
Wenn es noch die Möglichkeit gibt, dass die Markierung bei Level0 fehlt,
dann wäre die Umsetzung der Tabelle von Seite 88 auch möglich.
Vielleicht doch ein Bit gesetzt?
Werner M. schrieb:> Wird aber der Befehl LCALL 0C000H ausgeführt, so wird ein Reset> ausgelöst!
Es wird bestimmt kein Reset ausgelöst, sondern der Code rennt weiter bis
über 0x0000h.
Was für RAM und Gatter sind das denn, d.h. wie schnell?
Kann sein, die sind zu langsam. Ein PSEN-Zugriff ist ja deutlich kürzer
als über RD.
Nimm mal einen langsameren Quarz oder schalte davor den Prescaler für
den CPU-Takt ein.
Ob die HW-Lockbits gesetzt sind, kann man überprüfen, indem man nach dem
Start den EA-Pin auf GND legt. Beim gesicherten Chip wird EA gelatcht,
d.h. ein Ändern bleibt ohne Wirkung und das Programm aus dem Flash läuft
weiter.
Beim ungesicherten Chip wird aber sofort der Flash abgeschaltet und das
Programm stürzt ab.
Ich verstehe die Logik nicht ganz. Baustein IC5 ist ein UND-Gatter.
Deshalb ist HMEM im oberen Adressbereich HIGH, geht aber auf den
activ-low-Chipselect CE1. Eventuell hilft es, mit HIMEM auf den
activ-high-Chipselect CE2 zu gehen und CE1 fest auf LOW-Pegel zu legen.
Lt. Table 66. Program Lock Bits ist default Security
Level 4 programmiert.
Das ist auch sinnvoll, damit man seinen Code schützen kann, wenn man ihn
über den Bootloader flasht. Ansonsten könnte man ja mit einem externen
Flash den internen Flash auslesen.
Ohne einen parallel Programmer wird man das nicht ändern können.
Peter D. schrieb:> Was für RAM und Gatter sind das denn, d.h. wie schnell?
Standardmäßig nutze ich einen 20MHz Quarz. Ich habe nun einen Test mit
deaktiviertem X2-Mode und einen Quarz von 18,432MHz und 11,0592MHz
durchgeführt. Es bleibt bei dem beschriebenen Problem.
Der RAM hat eine Zugriffszeit von 70ns, dass dürfte schnell genug sein.
Für die UND-Gatter verwende ich einen 74HCT08.
Günni schrieb:> Ich verstehe die Logik nicht ganz. Baustein IC5 ist ein UND-Gatter.> Deshalb ist HMEM im oberen Adressbereich HIGH, geht aber auf den> activ-low-Chipselect CE1.
Genau, im unteren Bereich ist die Logik 0 und damit wird der RAM aktiv
(0000H-0EFFFH). Im oberen Bereich (0F000H-0FFFFH) ist er inaktiv und
wird für I/O-Anwendungen genutzt (diesen Teil habe ich weggelassen).
Peter D. schrieb:> Lt. Table 66. Program Lock Bits ist default Security> Level 4 programmiert.
Dann müsste aber im Bild Level2 markiert sein. Es ist aber scheinbar nur
Level0 aktiv, was auch schon ausreicht um keinen externen Programmcode
auszuführen.
Die Meinungen im Forum sind hier uneinig ob irgendein Security-Bit
gesetzt ist.
Gibt es eine kostengünstige Methode den µC parallel zu programmieren?
Welche Erfahrungen gibt es mit dem TL866II Plus?
Es gibt auch die neueren AT89LP51RD2/ED2/ID2. Die lassen sich auch über
SPI (4 Leitungen) programmieren und so die Lockbits rücksetzen.
Die haben zwar alle 64kB im Flash, mit dem FBS-Bit kann man aber zur
Laufzeit die oberen 32kB nach extern mappen.
Werner M. schrieb:> Wird aber der Befehl LCALL 0C000H ausgeführt, so wird ein Reset> ausgelöst!>> Wieso ist das so, wurde hier ggf. vergessen ein Register zu setzen?
Das ist so, weil die CE1-Beschaltung des RAMs nicht den erwarteten
Adressbereich (8000h-FFFFh) selektiert.
Wenn sich man die verschiedenen Adressbereiche ,0000h-7FFFh für die
unteren 32k und 8000h-FFFFh für die oberen 32k, in binärer Form
verdeutlicht, sollte klar sein, wie der CE1-Pin beschaltet werden muß um
den gewünschten Adressbereich auszuwählen.
G. O. schrieb:> Das ist so, weil die CE1-Beschaltung des RAMs nicht den erwarteten> Adressbereich (8000h-FFFFh) selektiert.
Die CE1-Beschaltung selektiert den Adressbereich von 0h bis 0EFFFh, dass
ist so gewollt und funktioniert auch. Ansonsten könnte ich auch nicht
mit MOVC oder MOVX in diesem Bereich zugreifen. Es wird aber die
Programmausführung verweigert.
Werner M. schrieb:> Dann müsste aber im Bild Level2 markiert sein.
Nein, das ist nur der Software-Lock, d.h. der bestimmt, was der
Bootloader darf.
Siehe: Table 69. Program Lock Bits of the SSB
Die Ausführungssperre und Lock des Parallel Programming macht jedoch der
Hardwarelock.
Siehe: Table 66. Program Lock Bits
Das aufzuheben geht nur mit Erase über einen parallel Programmer.
Werner M. schrieb:> Die CE1-Beschaltung selektiert den Adressbereich von 0h bis 0EFFFh, dass> ist so gewollt und funktioniert auch
Ok, habe ich verstanden.
Im Schaltplan ist /EA auf VCC gelegt. Damit externer Programmcode
ausgeführt wird, muß aber /EA=0 sein.
G. O. schrieb:> Im Schaltplan ist /EA auf VCC gelegt. Damit externer Programmcode> ausgeführt wird, muß aber /EA=0 sein.
Wenn /EA=0 ist wird der komplette Adressbereich für Code benutzt.
Wenn /EA=1 ist wird beim AT89C51RD2 für den unteren Bereich 32k Flash
und für den oberen Bereich externer Programmcode verwendet.
Peter D. schrieb:> Nein, das ist nur der Software-Lock, d.h. der bestimmt, was der> Bootloader darf.> Siehe: Table 69. Program Lock Bits of the SSB
Dann sollte man im Datenblatt auch mit der Nummerierung von 0 an
beginnen, um so Verständnisprobleme zu vermeiden.
> Die Ausführungssperre und Lock des Parallel Programming macht jedoch der> Hardwarelock.> Siehe: Table 66. Program Lock Bits
Diese werden im Bild mit Hardware Byte (HSB) angezeigt. Demnach ist auch
Security Level 4 programmiert (1111 1011, Bit 2)!
Weshalb kann ich mit Atmel Flip den zu flashenden Code noch
verifizieren, wenn das bei der parallelen Programmierung nicht mehr
funktioniert (bereits mit Level 3)?
> Das aufzuheben geht nur mit Erase über einen parallel Programmer.
Der TL866II Plus ist relativ preiswert. Er unterstützt den AT89C51RC der
auch die Security Bits hat. Somit sollte eigentlich der AT89C51RC2 damit
programmierbar sein.
Peter D. schrieb:> Es gibt auch die neueren AT89LP51RD2/ED2/ID2. Die lassen sich auch über> SPI (4 Leitungen) programmieren und so die Lockbits rücksetzen.> Die haben zwar alle 64kB im Flash, mit dem FBS-Bit kann man aber zur> Laufzeit die oberen 32kB nach extern mappen.
Der einfachere Weg ist wohl den Controller zu tauschen.
Der AT89LP51RC2 oder AT89LP51RD2 sind Pin kompatibel und haben noch
zusätzlich 4 I/O´s mehr. Problem, diese z.Z. zu kaufen (Chipmangel).
Werner M. schrieb:> Er unterstützt den AT89C51RC der> auch die Security Bits hat. Somit sollte eigentlich der AT89C51RC2 damit> programmierbar sein.
Eher nicht!
Die unterscheiden sich recht deutlich.
AT89C51RC:
"The programming interface needs a high-voltage (12-volt) program enable
signal"
Der AT89C51RC2 wird die 12V nicht mögen (siehe Datenblatt).
Peter D. schrieb:> Der AT89C51RC2 wird die 12V nicht mögen (siehe Datenblatt).
Hatte ich übersehen.
Schade das der AT89C51RC2 vom TL866II Plus nicht unterstützt wird.
Programmiergeräte wie SuperPro 610P und SmartProg2 schon.
Flip 3.4 habe ich noch nicht probiert. Aber man kann die LP
programmieren, indem man die C-Typen auswählt. Allerdings sind dann die
zusätzlichen Funktionen nicht verfügbar.
https://www.microchip.com/en-us/development-tool/flip
Unter "Supported Devices" sind sie jedenfalls aufgeführt.
Peter D. schrieb:> Es gibt auch die neueren AT89LP51RD2/ED2/ID2.
Ich habe gesehen, dass die neueren Versionen auch ein "Two-wire On-Chip
Debug Interface" haben.
Bei Microchip habe ich nur Toole für die AVR- und PIC-Serie gefunden.
Welcher Debugger unterstützt diese Serie?
8052_mit_Bussystem.png
(63 KB)
8052_mit_Bussystem.png
(63 KB)
