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?
Angehängte Dateien:
-
8052_mit_Bussystem.png
63 KB -
8052_mit_Bussystem.png
63 KB
:
Bearbeitet durch User
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?
Angehängte Dateien:
-
AT89C51RC2-Atmel_Flip.png
100 KB
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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
AT89C51RC2-Atmel_Flip.png
100 KB
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?
:
Bearbeitet durch User
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).
Angehängte Dateien:
-
AT89C51RC2-Atmel_Flip.png
100 KB
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
AT89C51RC2-Atmel_Flip.png
100 KB
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: > Die Meinungen im Forum sind hier uneinig ob irgendein Security-Bit > gesetzt ist. Glücklicherweise ist das Datenblatt eindeutig.
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.
:
Bearbeitet durch User
Peter D. schrieb: > Es gibt auch die neueren AT89LP51RD2/ED2/ID2. Diese sollten sich eigentlich auch über die Atmel Flip Software programmieren lassen. https://www.microchip.com/en-us/development-tool/flip#Additional%20Resources Jedoch können diese in der Software nicht ausgewählt werden! Wie sollen dann diese programmiert werden?
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.
:
Bearbeitet durch User
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?
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.