Hallo Forum. Ich habe hier zwei AT89S8252 liegen, die ich in ein Projekt einbauen möchte. Ich habe die Platine mit Quarz und allen benötigten Kondensatoren vorbereitet, Controller #1 eingesetzt und mit UBSprog (AT89prog-Firmware) ein Demoprogramm raufgeladen, welches bei mir erfolgreich und wie erwartet eine LED an Port 1 zum Blinken gebracht hat. Ich habe mich also gefreut und wollte mein eigenes Programm schreiben, zuerst mal in Asm und mit AR31 assembliert. Aufgabe des Programms: die gleiche LED dauerhaft einschalten. Keine Reaktion, LED blinkt fröhlich weiter (obwohl ich das neue Programm hochgeladen habe!). Also dachte ich, der 1. Controller hat vielleicht einen Schuss weg (ESD? Keine Ahnung..) und habe den 2. eingesetzt. Programmiert, und voila: LED leuchtet. Programm nochmal geändert, funktioniert auch: LED wieder aus. Das ein paar mal Wiederholt, um auch ganz sicher sein, dass er diesmal mehrmals zu programmieren ist. Dann habe ich absichtshalber einen Fehler in das Programm gebaut (diesmal C, mit SDCC kompiliert), nur um mir mal die Fehlerausgabe des Programms anzuschauen. Nach Berichtigung des Fehlers habe ich das korrekte Programm erheut hochgeladen, doch nun zeigt auch dieser zweite Controller keine Reaktion mehr. Frage: Was muss ich beachten, wenn ich mit diesen betagten Chips hantiere? Ich habe zuerst gedacht, ich hätte vielleicht aus versehen das Fusebit zum Abschalten der seriellen Programmierung gesetzt. Jedoch steht im Datenblatt, dass dies nur via parallele Programmierung geht. Puh. Ein OTP ist das Ding auch nicht. Die Schaltung läuft auf 24 MHz, dieser Quarz läuft stabil und die Versorgung ist einwandfrei. Ich habe #EA/VPP nach VCC gezogen und RESET nach GND. Das ist richtig so, ja? Vielleicht hat hier jemand Erfahrung mit diesen Kontrollören und kann mir Tipps geben, woran oben geschilderte Probleme liegen könnten. Gruß, Paul
Vergleich mal das ErrataSheet mit deiner Chip-Revision. Im SPI-Programmiermodus kann es bei früheren Chip-Revisionen dazu kommen, dass die Dinger nur noch im Parallelprogrammer wieder ans Leben zu bekommen sind. Ich halte diesen Fall bei dir für unwahrscheinlich, da ich sonst eine Fehlermeldung des Programmers beim Verify erwartet hätte, aber man weiss ja nie. Ansonsten könnte ich mir vorstellen, dass du die Lockbits gesetzt hast, welche nur durch einen Full-Chip-Erase wieder zu löschen sind, aber auch hier wäre eine Fehlermeldung vom Programmer der Soll-Fall... Ansonsten bleibt nur noch: Schaltplan, Programmersetup, etc. Ralf
Ich würd mal sagen, das liegt an Deinem Programmer. Ich hab in nem älteren Projekt AT89S8252 massenweise eingesetzt und noch nie ließ sich einer nicht mehr über SPI programmieren. Der Resetpin wird bei mir aber nicht auf GND gelegt, sondern mit vom Programmer kontrolliert. Er dient ja quasi zur Synchronisation wie das /SS bei jedem anderen SPI-Slave. Peter
Danke für eure Antworten. Ich könnte kotzen: "Experiments using AT89S devices have shown that if the user code writes to any of the ISP I/O pins (MOSI, MISO, SCK) within approximately 500 ms of the user code coming out of RESET condition, any subsequent serial programming operation fails. The problem is then that the only way to re-program the device successfully is to physically remove it from the target board and erase it in a parallel programmer. Make sure that the user code does not access any of the ISP I/O pins within 500 ms of coming out of RESET condition." WUAAARGH. Jetzt macht alles Sinn: Beim letzten erfolgreichen Programmierversuch habe ich den kompletten Port 1 (dort hängen die ISP-Pins dran!) auf 1 gesetzt. So ein Mist, jetzt darf ich irgendwie einen parallelprogrammer selber zusammenzimmern. Zum Thema Verify: Das Auslesen des Chips unterstüzt Benedikt Sauters at89prog-Firmware leider noch nicht. Daher gibts auch keinen Verify..der Programmer checkt nicht einmal die Device-ID, soweit ich das beurteilen kann. Naja. Danke euch, hätte eigentlich selbst drauf kommen müssen, mir die Errata reinzuziehen. Gruß, Paul
> Ich könnte kotzen:
Hast du noch eine Tuete ueber? Dann kann ich dir noch was erzaehlen.
Die Teile haben ja eine interne Firmware fuer das brennen. Die kann
fehlerhaft gestartet werden wenn der Prozessor mit Unterspannung laeuft,
also z.B die Betriebspannung nicht richtig hoch kommt. Und zwar selbst
dann wenn man den Reseteingang dauerhaft auf Reset legt! Und dann wird
durch zufall irgendwas in der Firmware gestartet und das kann auch die
Routine zum loeschen eines Blocks sein.
Olaf
Paul Wilhelm schrieb: > Make sure that the user code does not access any of the > ISP I/O pins within 500 ms of coming out of RESET > condition." Komisch, damit hatte ich noch nie Probleme. staun Und ich mache genau das! Allerdings benutze ich auch einen eigenen SPI-Programmer. > So ein Mist, jetzt darf ich irgendwie > einen parallelprogrammer selber zusammenzimmern. Naja, Chip-Erase reicht ja. Also einen IC Sockel mit Quarz, 5V, 12V, GND. 6 Pins auf korrekten Pegel ziehen und einen 10ms L-Impuls an ALE/_PROG Anlegen. Infos im Datenblatt. ... kribbelt mir schon etwas in den Fingern, mir den mal anzusehen. ;-) Gruß Jobst
Wow, das Ding kann ja richtig fies sein! Glücklicherweise ist das manuelle Durchführen eines Chip-Erase sehr einfach. Habe beide Kontrollöre eben erfolgreich wiederbelebt und werde den Port 1 vorerst meiden, so viele Pins brauche ich sowieso nicht. ;-) Werde gleich mal einen Eintrag in meinem Blog schreiben: AT89S8252-Crashkurs. Gruß, Paul
Magst Du die Killer-Programme hier mal posten? Ich bekomme meine Controller nicht tot. Damit möchte ich mal herumspielen. Gruß Jobst
> Ich bekomme meine Controller nicht tot.
Dann ist deiner wohl nicht von diesem Problem betroffen!
Hier trotzdem das pupssimple Programm, welches - ganz unerlaubt -
innerhalb der ersten 500ms die ISP-Pins beschreibt.
1 | #include <at89S8252.h> |
2 | |
3 | void main(void) {
|
4 | while (1) {
|
5 | P1 = 0xff; |
6 | } |
7 | } |
@Olaf:
> Die Teile haben ja eine interne Firmware fuer das brennen.
Aber nicht der 825x. Sicher, dass du da nicht was verwechselst?
Die AT89C51xx2 ja, die können sich mittels Bootloader selber flashen,
aber der 8252/8253 sicherlich nicht.
Ralf
Ralf schrieb: > @Olaf: >> Die Teile haben ja eine interne Firmware fuer das brennen. > Aber nicht der 825x. Sicher, dass du da nicht was verwechselst? > Die AT89C51xx2 ja, die können sich mittels Bootloader selber flashen, > aber der 8252/8253 sicherlich nicht. > > Ralf Sie haben zwar keinen Bootloader, aber trotzdem ist es eine Firmware, mit der man ja auch kommuniziert. Gruß Jobst
Paul Wilhelm schrieb: >> Ich bekomme meine Controller nicht tot. > > Dann ist deiner wohl nicht von diesem Problem betroffen! > > Hier trotzdem das pupssimple Programm, welches - ganz unerlaubt - > innerhalb der ersten 500ms die ISP-Pins beschreibt. > >
1 | #include <at89S8252.h> |
2 | > |
3 | > void main(void) {
|
4 | > while (1) {
|
5 | > P1 = 0xff; |
6 | > } |
7 | > } |
Ich bin verblüfft darüber, daß Du 0xFF dort hinein schreibst und dies zu dem Problem führt ... 0xFF ist ja der default-Wert. Du schreibst das immer wieder dort hinein ... Ich werde das gleich nochmal testen ... Gruß Jobst
0xFF ist default, also alle Pins sind nach dem Reset HIGH? Das ist doch das SFR, mit dem ich Port 1 schalte, oder? Ich habe bislang quasi Null Erfahrung von 8051-Geschichten. Ich dachte Px ist der Port. Wie man Pins auf High Impedance schaltet oder von einem Pins liest weiß ich leider noch nicht. Vielleicht kann mir das hier jemand beantworten? :-) Gruß, Paul
Paul Wilhelm schrieb: > void main(void) sollte vielleicht auch besser void void(void) heissen - Würde besser passen :-D Ich habe dies
1 | main: MOV P1, #0xff |
2 | SJMP main |
in einen AT89S52 und einen AT89S8253 geflasht und danach auch wieder connecten können und den Chip löschen können. AT89S8252 müsste ich auch noch welche haben - Test folgt. Gruß Jobst
Paul Wilhelm schrieb: > 0xFF ist default, also alle Pins sind nach dem Reset HIGH? Das ist doch > das SFR, mit dem ich Port 1 schalte, oder? > > Ich habe bislang quasi Null Erfahrung von 8051-Geschichten. > Ich dachte Px ist der Port. > > Wie man Pins auf High Impedance schaltet oder von einem Pins liest weiß > ich leider noch nicht. > Vielleicht kann mir das hier jemand beantworten? :-) > > Gruß, > Paul Beim 8051 ist der Port Pullupped oder Low. Port 0 ist eine Ausnahme: Open-Drain DDR oder ähnliches wie beim AVR gibt es nicht. Ein Port kann im H-Zustand als Eingang verwendet werden. Nachtrag: Ein Port, der vom uC auf L gezogen ist, extern auf H zu setzen, zerstört den Transistor, der den Port auf Masse zieht. Gruß Jobst
Jobst M. schrieb: > Komisch, damit hatte ich noch nie Probleme. staun > Und ich mache genau das! > Allerdings benutze ich auch einen eigenen SPI-Programmer. Dito. Ich denke, es liegt an unsauberer Programmer-Firmware. Ich hab nen AT89C2051 fürs Updaten programmiert und nie Probleme damit gehabt. Peter
Olaf schrieb: > Die Teile haben ja eine interne Firmware fuer das brennen. Das ist Quatsch, die mit Bootloader heißen anders. Der AT89S8252 hat keine Firmware, sondern macht alles über SPI, also ein Schieberegister (Hardware). > Die kann > fehlerhaft gestartet werden wenn der Prozessor mit Unterspannung laeuft, > also z.B die Betriebspannung nicht richtig hoch kommt. Und zwar selbst > dann wenn man den Reseteingang dauerhaft auf Reset legt! Und dann wird > durch zufall irgendwas in der Firmware gestartet und das kann auch die > Routine zum loeschen eines Blocks sein. Ich weiß ja nicht, welche Schweinereien ihr mit euren 8252 anstellt, aber bei mir laufen die wie dumm und vergessen auch nicht ihre Programmierung. Blöd war nur, daß Atmel die ohne gleichwertigen Ersatz abgekündigt hat, da mußten wir dann auf AT89C51CC03 umentwickeln. Der AT89S8253 war als Ersatz völlig untauglich, da er den EEPROM beim Update nicht behält und anders programmiert wird. Peter
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.