www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Launischer AT89S8252


Autor: Paul Wilhelm (mosfetkiller)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Paul Wilhelm (mosfetkiller)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Paul Wilhelm (mosfetkiller)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Magst Du die Killer-Programme hier mal posten?
Ich bekomme meine Controller nicht tot.
Damit möchte ich mal herumspielen.


Gruß

Jobst

Autor: Paul Wilhelm (mosfetkiller)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.
#include <at89S8252.h>

void main(void) {
  while (1) {
    P1 = 0xff;
  }
}

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
>
>
#include <at89S8252.h>
> 
> void main(void) {
>   while (1) {
>     P1 = 0xff;
>   }
> }

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

Autor: Paul Wilhelm (mosfetkiller)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paul Wilhelm schrieb:
> void main(void)

sollte vielleicht auch besser

void void(void)

heissen - Würde besser passen :-D



Ich habe dies
main:    MOV     P1, #0xff
         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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.