Halli Hallo, ich habe gerade ein Problem dabei meinen AT89S52 in Betrieb zu nehmen und ein allererstes Programm drauf zu laden. Kennt sich jemand mit diesem µC aus und kann mir vielleicht helfen? Folgendes habe ich bis jetzt gemacht: Nach dem Schaltplan, den ich hier als Bild angehängt habe, hab ich einen 12MHz Quarz, und dahinter zwei 33pF Kondensatoren an die Pins XTAL1 (Pin19) und XTAL2 (Pin18) geschaltet. Dann hab ich an den RST (Pin9) ein Bein eines Tasters angeschlossen. Von dem Bein des Tasters geht ein 10kOhm Widerstand an Masse und ein 10uF Kondensator an Plus. Das andere Bein des Tasters geht ebenfalls an Plus. Außerdem habe ich VCC(Pin 40) und EA/VPP(Pin31) mit Plus verbunden. Von P1.0(Pin1) habe ich eine LED mit Plus verbunden, die ich in meinem Programm anschalten will. Als Programmieradapter benutze ich ein USBASP (http://www.ebay.de/itm/231303444767?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT) Hier habe ich den Jumper JP1 auf 5V gesteckt und die nach dem Belegungsplan, der in dem 2. Bild dargestellt ist mit den Pins auf dem µC verbunden. MOSI mit Pin6 RST mit Pin9 SCK mit Pin8 MISO mit Pin7 VCC mit Plus GND mit Masse Ich habe den Treiber für USBASP heruntergeladen http://www.fischl.de/usbasp/ Und ProgISP heruntergeladen und gestartet http://www.electrodragon.com/w/ProgISP Dann habe ich das Labornetzteil auf 5,5V eingestellt und mit Masse und Plus verbunden. Wenn ich nun allerdings bei ProgISP als "SELECT CHIP" den AT89S52 auswähle, dann kommt beim Aufruf von "Verify Flash" die Fehlermeldung "Chip Enable Program Error". Ich habe Google auch schon ordentlich gequält und viele Sachen ausprobiert, aber egal was ich mache, die Fehlermeldung bleibt. Ich würde mich echt freuen wenn mir jemand helfen könnte
Ich habe jetzt noch einmal Bilder gemacht und die hier hochgeladen und alles noch einmal durchgemessen. Mir ist mittlerweile auch aufgefallen, dass ich den µC nicht mit GND an Masse angeschlossen hab. Das ist also mittlerweile richtig. Der Fehler kommt aber trotzdem noch. an VCC 5,5V an EA/VPP 5,5V an P1.0 5,5V an MOSI, MISO, CLK 5,5V an RST 1,5V an XTAL2 4V an XTAL1 2,4V an GND 0V
Mach mal den 10uF Kondensator am Reset drastisch kleiner, 0.1uF als Test.
:
Bearbeitet durch User
Hast du an dem Programmer mal getestet, ob RST da auch so nach Plus geht wie der Taster? Bei den AVR ist das ja anders rum.
Ist die 5V am µC überhaupt nicht abgeblockt? Da braucht es auf jeden Fall mit einer möglichst kleinen Schleife einen Kondensaotor zu GND. 100nF sind OK. Außerdem kommt mir der Aufbau des Quarzes und der Kondensatoren sehr großräumig vor. Das baut man eigentlich so klein wie möglich. Würde mich nicht wundern wenn der Oszillator nicht schwingt. Kannst Du das überprüfen? Warum 5.5V und nicht 5?
Hey.. danke für eure schnellen Tipps ihr beiden ;) Ich hab jetzt den 10uF gegen 100nF ausgetauscht. Danach hat es auch einmal geklappt. Er hat den µC erkannt und Programmieren hat auch funktioniert. Leider ging es kurz danach schon wieder nicht mehr und jetzt geht es wieder. Immer dann wenn es nicht ging, hab ich am Reset iwas so um die 3V gemessen. Dann hab ich den Kondensator mal raus genommen und ein bisschen entladen lassen und dann gings wieder. 10 Minuten später waren es wieder über 1V und es ging nicht mehr. Irgendwas läuft da wohl noch mit dem Kondensator falsch :( @Michael wie meinst du das mit dem Reset? Die Reset-Leitung vom Programmer geht direkt auf den Pin RST vom µC. Und der wird mit dem Pull-Down-Widerstand auf LOW gezogen. Das klappt auch soweit. Normalerweise ist die Spannung ca. 0V. Wenn man den Taster drückt geht sie hoch auf 5,5V
Hallo Anon Anon, wo ist denn das Problem? Läuft der Controller nicht, oder liegt es am Programmieren? Dein Programmiergerät und die zugehörige Software kenne ich nicht, dafür aber den Kontroller. Wenn der richtig beschaltet ist (dein Plan sieht danach aus), sollte er ordentlich laufen. Und wenn er das tut, dann gibt er am Pin-30 "ALE", die Taktfrequenz / 6 aus. Bei deinem 12MHz-Quarz also 2MHz. Das kannst du mit dem Oszi oder Frequenzzähler überprüfen. Hast du keines der beiden Geräte, geht es auch mit einem Multimeter. Am ALE-Pin sind, bei Gleichspannungsmessung, ca. 1,5V gegen GND zu messen. Die seltsame Spannung rührt vom asymetrischen Puls/Pausenverhältnis des Signals her. Kannst du den vorhandenen ALE messen, läuft der 89S52 sicher und das Problem macht die Programmierung. Fehlt ALE, dann läuft schon der Controller nicht und du mußt den Fehler dort suchen. Gruß. Tom
Das Problem ist der 10k Widerstand in der Reset-Schaltung. So lange der Spannungspegel nicht unter 2.2 V sinkt, wird der Controller nicht starten bzw. programmiert werden können. Tausch den 10k gegen 1k aus! Normaler Weise brauchst Du den Widerstand nicht, da intern schon einer vorhanden ist.
Also ALE habe ich gemessen und 2Mhz liegen an. Von daher müsste der µC ja laufen. Allerdings komme ich immernoch nicht von meinen 3V runter. Auch mit 1K Widerstand oder ganz ohne. Ich habe auch testweise den Kondensator rausgenommen. Aber selbst dann hab ich auf dem Pin über 3V. Ich hab dann mal den Pin vom Programmiergerät geprüft. Wenn ich den abziehe messe ich auf ihm ca. 1,5V und am µC RST-Pin sind dann trotzdem noch über 3V, obwohl der bei nicht gedrücktem Taster ja eig direkt über den Widerstand auf Masse geht. Welche Funktion hat eigentlich überhaupt der Kondensator? Ist der wegen dem Prellen vom Taster? Danke übrigens, dass ihr alle so fleißig helft :)
Anon Anon schrieb: > @Michael wie meinst du das mit dem Reset? > Die Reset-Leitung vom Programmer geht direkt auf den Pin RST vom µC. Und > der wird mit dem Pull-Down-Widerstand auf LOW gezogen. Er muß aber analog wie dein richtig eingezeichneter Taster nach H gezogen werden. Das ist ein Unterschied zum AVR.
Hallo Anon Anon, wenn der ALE da ist, dann läuft dein 89S52. Ich habe grad eine funktionierende Schaltung vor mir und gebe dir mal meine, mit dem Multimeter, gemessenen Werte: In Betrieb: Versorgung: 5,15V / ALE: 1,7V / Reset: 0,02V Unter Reset: Versorgung: 5,15V / ALE: 5,15V / Reset: 4,3V Reset kommt bei meiner Schaltung aus einem TL7705, mit einem Pulldown-Widerstand (an Pin6-TL7705) von 4k7 auf GND. Der Resetkondensator am TL7705 hat eine Kapazität von 22µF. Gruß. Tom
Hallo nochmal.. ich habe gestern nochmal alles zusammen mit meinem Vater (der Elektriker ist) kontrolliert und habe dann letztlich auch ziemlich genau die gleichen Spannungen gemessen wie TomA. Die Reset-Schaltung müsste von daher eigentlich richtig sein. Allerdings ist es trotzdem nur immer mal wieder möglich, den µC mit dem Programm zu erkennen. Die meiste Zeit klappt es auf jeden Fall nicht. Michael_ schrieb: > Er muß aber analog wie dein richtig eingezeichneter Taster nach H > gezogen werden. > Das ist ein Unterschied zum AVR. Aber das müsste doch genau falsch sein. Dann wäre der RST-Pin bei gedrücktem Taster genauso wie bei nicht gedrücktem HIGH. Denn laut dem Datenblatt bewirkt ein HIGH ein Reset und dann wäre ja ständig der Reset aktiviert.
1 | RST |
2 | Reset input. A high on this pin for two machine cycles while the oscillator is running resets the |
3 | device. This pin drives high for 98 oscillator periods after the Watchdog times out. The DISRTO |
4 | bit in SFR AUXR (address 8EH) can be used to disable this feature. In the default state of bit |
5 | DISRTO, the RESET HIGH out feature is enabled. |
Anon Anon schrieb: > Aber das müsste doch genau falsch sein. Dann wäre der RST-Pin bei > gedrücktem Taster genauso wie bei nicht gedrücktem HIGH. Wenn nicht gedrückt ist, zieht der R auf Null und der C ist geladen. Du brauchst einen positiven Impuls. http://www.embeddedgurukul.com/at89c2051/ Beim AVR einen negativen. http://winavr.scienceprog.com/hardware-for-prototyping/typical-circuits-of-avr-microcontrollers-for-fast-start.html
:D ich glaube wir reden aneinander vorbei, meinen aber das gleiche. Der Widerstand zieht den RST-Pin normalerweise auf Masse(LOW), Der Kondensator "überbrückt" den Taster, denn beide gehen direkt vom RST des µC zu Plus. Wird jetzt der Taster gedrückt gibt es einen "positiven Impuls" wie du gesagt hast. (Also ein HIGH auf dem RST-Pin) und er Reset wird ausgelöst. Ist das so jetzt richtig? Falls ja dann funktioniert meine Reset-Schaltung
Hallo Anon Anon, mit deinem Reset ist alles in Ordnung, das kannst du schon an der Messung am ALE-Pin sehen. Wenn ALE vorhanden ist (ca. 1,5V), dann läuft der µC. Bei Reset bleibt der ALE aus (VCC am ALE-Pin). Das Problem liegt am programmieren oder der Verbindung zum Programmiergerät! Gruß. Tom
TomA schrieb: > mit deinem Reset ist alles in Ordnung Jein... das aktive ALE zeigt, dass Reset freigegeben wird. Das Programmieren funktioniert aber nur, wenn Reset aktiv ist. Da muss das Programmiergerät weit genug und schnell genug ziehen können - deshalb auch mein Vorschlag, den Kondensator zu verkleinern. Damit ging es wenigstens sporadisch.
@Georg: Da gebe ich dir Recht. Ich hatte diesbezüglich auch schon Probleme (vor allem mit ISP) und führe bei meinen Schaltungen die unterschiedlichen Reset-Signale über 220-Ohm Widerstände zusammen, wie im Anhang gezeigt. @Anon: Deine Schaltung ist ja nur gesteckt, da kannst du das schnell und einfach ausprobieren. Bei der Gelegenheit kannst du auch gleich zwischen Reset-Kondensator und Taster einen kleinen Widerstand (ca. 100-Ohm), damit der Kondensator nicht über Kurzschluß entladen wird, einfügen. Das ist nicht sehr wichtig, aber der Kondensator dankt es mit längerer Lebensdauer. Gruß. Tom
Anon Anon schrieb: > Ist das so jetzt richtig? Falls ja dann funktioniert meine > Reset-Schaltung Na klar. Aber der Programmer muß den Taster simulieren. Beim programmieren muß der Programmer Reset machen, mit einem H-Impuls. Wenn er schwach ist, hilft wie oben genannt, den C verkleinern. Teste doch mal beim programmieren, ob da ein positiver Impuls ankommt.
Michael_ schrieb: > Aber der Programmer muß den Taster simulieren. > Beim programmieren muß der Programmer Reset machen, mit einem H-Impuls. > Wenn er schwach ist, hilft wie oben genannt, den C verkleinern. > Teste doch mal beim programmieren, ob da ein positiver Impuls ankommt. Aah ich glaube jetzt versteh ich, was du die ganze Zeit sagen willst. Ok ich versuche mal ob ich irgendwas messen kann, allerdings hab ich momentan nur ein Multimeter da wird man wsl nicht viel sehen. Der Logikanalysator steht noch auf der Wunschliste. Georg G. schrieb: > Da muss das > Programmiergerät weit genug und schnell genug ziehen können - deshalb > auch mein Vorschlag, den Kondensator zu verkleinern. Den Kondensator habe ich ja mittlerweile von 10uF auf 100nF verkleinert. Ist der Wert okay? Was genau meinst du mit "weit genug und schnell genug ziehen können"? Dass das Programmiergerät die Spannung auf ein eindeutiges HIGH zieht(weit genug)? Und dies zeitlich schnell genug geht? TomA schrieb: > Da gebe ich dir Recht. Ich hatte diesbezüglich auch schon Probleme (vor > allem mit ISP) und führe bei meinen Schaltungen die unterschiedlichen > Reset-Signale über 220-Ohm Widerstände zusammen, wie im Anhang gezeigt. Alles klar, das probiere ich dann später mal aus. Was hat das elektronisch gesehen für einen Effekt? 220Ohm sind ja nicht gerade viel
Der Reset Pin wird beim Programmieren ja von der Software gesteuert. Ich denke diese Startet auch nach dem Flashen den MC !? Somit kannst du die R C Kombination auch ganz weglassen, diese generiert den Reset später in der fertigen Schaltung.
Pack' einfach, vorübergehend, R2 und C3 in die Bauteilekiste. Dann geht zwar nur der "manuelle" Reset, aber Du kannst den Rest überprüfen. Ich kenne die Empfehlungen zu dem Chip nicht, aber wenn der Quarz nicht zappelt, reduzier' doch die zwei 33pF Kondensatoren.
Anon Anon schrieb: > Dass das Programmiergerät die Spannung auf ein eindeutiges HIGH > zieht(weit genug)? Und dies zeitlich schnell genug geht? Genau das. Wenn Reset aktiv ist, lauscht die CPU an den Leitungen, ob das magische Wort "programmieren bitte" kommt. Der Programmer gibt "Reset" aus, kann aber nicht kontrollieren, was tatsächlich passiert. Also wartet er kurz und brüllt dann den Befehl. Wenn keine Antwort kommt, wird aufgegeben. Ohne richtige Meßtechnik ist es etwas mühsam, da den Fehler zu suchen.
Anon Anon schrieb: > ah ich glaube jetzt versteh ich, was du die ganze Zeit sagen willst. Ok > ich versuche mal ob ich irgendwas messen kann, allerdings hab ich > momentan nur ein Multimeter da wird man wsl nicht viel sehen. Der > Logikanalysator steht noch auf der Wunschliste. Ich benutze dazu so einen Prüfstift. http://www.reichelt.de/Komponententester/LOGIK-TESTER/3/index.html?&ACTION=3&LA=2&ARTICLE=10536&GROUPID=4024&artnr=LOGIK+TESTER Den kann man auch leicht selbst bauen. Anleitungen gibt es dazu genug. Such mal nach TTL Logik Prüfstift.
Soo ich bin gerade im örtlichen Hackerspace und probiere hier mein Glück. Wir haben jetzt mal testweise die komplette Reset-Schaltung abgeklemmt. Außerdem haben wir gemerkt, dass meine Pin-Belegung dich ich für den USBASP angenommen hab nicht stimmte. Die Pins 4 und 6 sind dort nämlich nicht immer GND, sondern je nachdem auch gelegentlich auch mal noch zusätzlich noch RxD oder TxD. Die Pins 8 und 10 sollen allerdings immer GND sein. Seit dem wir Masse auf Pin 10 haben, gibt es auch kein merkwürdiges Verhalten mehr, dass der µC nur ab und zu erreichbar ist. Es ist jetzt immer möglich den µC zu programmieren. Allerdings glaube ich nicht, dass der µC wirklich programmiert wird. Denn selbst trotz meinem Programm :
1 | $include(reg515c.inc) |
2 | |
3 | main: |
4 | setb p1.0 |
5 | clr p1.1 |
6 | setb p1.2 |
7 | clr p1.3 |
8 | jmp main |
9 | end |
sind alle Pins auf HIGH. Außerdem schlägt das Verify Flash jedes mal fehl. Wenn ich Read Flash aufrufe sieht man halt auch, dass mein Programm nicht auf dem Flash angekommen ist. Außerdem gibt es anscheinend einen Fehler beim lesen der Signatur des Controllers. Denn hier liest das Programm immer FF:FF:FF statt 1E:52:06. Ansonsten läuft der Controller jetzt. ALE hat seine 2MHz. Er lässt sich bloß anscheinend nicht programmieren
Eigentlich hab ich sowas auch noch vor und habe mir vor einiger Zeit auch so einen Programmer für wenig Geld aus China kommen lassen. Vor allem, weil er die 51 programmieren kann. Leider ist da keine Beschreibung dabei. Für AVR kann ich ihn mit der Soft Khazama und Extreme Burner betreiben. Nun hab ich mir den mal angeschaut und festgestellt, das das RST über 100 Ohm zu einem Jumper J2 führt. Was hat es damit auf sich? Auf deinem Programmer könnte das der J3 sein. Guck da mal, ob der zum RST führt. Vielleicht muß man den setzen, damit das RST umgekehrt wie bei den AVR ist? Hast du eine Beschreibung dazu?
Michael_ schrieb: > Nun hab ich mir den mal angeschaut und festgestellt, das das RST über > 100 Ohm zu einem Jumper J2 führt. Was hat es damit auf sich? > Auf deinem Programmer könnte das der J3 sein. Wo hast du einen Schaltplan gefunden, der an JMP einen 100Ohm Widerstand hat? Die Version die ich habe hat den JMP1 : um zwischen 3,3V und 5V Betriebsspannung wechseln zu können JMP2 : wird gebrückt, während der Programmer selbst mit einer neuen Firmware geflasht wird. (Dieser JMP ist bei vielen China-Platinen nicht bestückt) JMP3 : wird gebrückt um den Programmer auf seine langsamste Programmiergeschwindigkeit zu setzen. (Auch dieser JMP ist bei vielen China-Platinen nicht bestückt)
Hier jetzt noch einmal der momentane Stand der Dinge : Ich war gestern im Hackerspace (so einem Elektronikverein) bei mir in der Stadt und hab mit drei anderen Leuten 5 Stunden lang versucht, den µC zum laufen zu bringen. Folgendes haben wir gemacht: 1. Die Resetschaltung haben wir komplett entfernt. Der Reset geht daher jetzt direkt mit einem Pull-Down-Widerstand an Masse. Außerdem steckt der Reset-Pin des Programmers direkt auf dem RST-Pin des µC. Das setzen des Resets übernimmt also komplett der Programmer. > Hier konnten wir auch mit dem Multimeter messen, dass der Programmer beim lesen (sehr lange) und beim schreiben (ganz kurz) den RST-Pin auf HIGH zieht. Die "Reset-Schaltung" sollte somit, vorrausgesetzt das Timing des Resets stimmt, richtig sein 2. Masse am ISP-Programmer von Pin 4 auf Pin 10 umgesteckt, da manche USBasps auf Pin4 noch Rxd oder Txd haben. > Seit der Änderung war der Controller fast immer "erreichbar". Vorher konnte ich ihn ca. in 1 einem von 10 Fällen programmieren. Danach in 9 von 10 Fällen. Ansonsten kam ein Chip-Enable-Programm- Error. > Hier wurde allerdings schnell klar, dass es beim programmieren zwar keine Fehlermeldung mehr gab, im Flash des µC aber auch keine Änderung war. Das Programm kam also warum auch immer nicht an. 3. Währendessen haben wir immer wieder kontrolliert, ob an VCC und GND des µC die 5V ankommen und ob 2MHz an ALE anliegen. Beides war immer der Fall. 4. Zwischendurch haben wir es nur mit der Spannung des Netzteils versucht und das Plus vom Programmer komplett abgesteckt. > Keine Änderung 5. wir haben den Quarz und die Kondensatoren komplett abgeklemmt. > Kein Erfolg. Jetzt hatten wir nicht mal mehr einen laufenden µC, da dieser wsl keine interne Oszillatorschaltung hat. Also kam der Quarz wieder ran. 6. Wir haben die Firmware des Programmers auf folgende geändert, da diese extra für 8051er sein soll: http://www.circuitvalley.com/2011/06/usb-8051-avr-microcontroller-programmer.html > Danach war es möglich mit Erase Chip, den kompletten Flash des µC auf FFFFFFFFFFFF... zu schreiben. Das Programmiernen mit meinem Programm als hex-File :
1 | $include(reg515c.inc) |
2 | |
3 | main: |
4 | clr p1.0 |
5 | setb p1.1 |
6 | clr p1.2 |
7 | setb p1.3 |
8 | jmp main |
9 | end |
führte zwar nicht mehr zu einem Fehler. Im Flash änderte sich jedoch auch nichts. Wir haben nach jeden Write Flash, wieder mit Read Flash gemacht und der Inhalt blieb bei den gelöschten FFFFFFFFF... Irgendwann später kamen dann wieder, ohne dass wir irgendeine Änderung vorgenommen hatten Chip-Enable-Programm-Errors. Nach dem wir des öfteren die Spannung wieder abgezogen haben, den Programmer wieder neu eingesteckt haben und manuell ein paar Resets gemacht haben. Hat es dann ein zwei mal funktioniert den µC TATSÄCHLICH zu programmieren. Wie im oben angegebenen Programm konnten wir an p1.0 ein LOW p1.1 ein HIGH p1.2 ein LOW p1.3 ein HIGH messen Danach kamen dann beim erneuten programmieren zwar keine Fehlermeldungen mehr. Der Flash änderte sich aber auch nicht mehr. 7. Aus lauter Verzweiflung haben wir dann den µC gegen einen definitiv noch nagelneuen ausgetauscht. > Nach 10 Minuten Chip-Enable-Programm-Errors gelang es uns den µC zu erst ohne Fehler, aber auch ohne "Effekt" auf den Inhalt zu programmieren. Kurz darauf ließ er sich zwei mal mit verschiedenen Programmen programmieren und das Programm kam auch tatsächlich im Flash an. Kurz danach kamen wieder Errors und nichts funktionierte mehr. 8. Wir haben VCC und GND am µC mit einem Entstörungskondensator verbunden, das Netzteil weggestellt (wegen evtl. Störungen) und die Schaltung nur noch mit der Spannung des Programmers betrieben. > Es gab keine Änderungen und weiter Errors. 9. Feierabend für gestern -.- Hat noch irgendjemand eine Idee??
Michael_ schrieb: > Nun hab ich mir den mal angeschaut und festgestellt, das das RST über > 100 Ohm zu einem Jumper J2 führt. Was hat es damit auf sich? > Auf deinem Programmer könnte das der J3 sein. Guck da mal, ob der zum > RST führt. > Vielleicht muß man den setzen, damit das RST umgekehrt wie bei den AVR > ist? > Hast du eine Beschreibung dazu? Guck dir mal das hier an: http://www.circuitvalley.com/2011/06/usb-8051-avr-microcontroller-programmer.html bzw. http://www.8051projects.info/resources/usb-8051-avr-programmer.23/
Dank erst einmal. Anon Anon schrieb: > Wo hast du einen Schaltplan gefunden, der an JMP einen 100Ohm Widerstand > hat? Ich habe so einen: ebay 151302570060 Rechts unten der Mehrfach-R. Wahrscheinlich nur Angstwiderstände. Praktisch kann ich noch nichts machen, da ich ein altes Projekt wiederbeleben will und nur der Prozessor vorhanden ist.
aah okay.. das scheint noch ein anderer Programmer zu sein als meiner. Der den du da hast, der unterstützt allerdings auch die 8051er serie nicht :
1 | Supported microcontrollers include: |
2 | Mega Series |
3 | ATmega8 ATmega48 ATmega88 ATmega168 ATmega328 |
4 | ATmega103 ATmega128 ATmega1280 ATmega1281 ATmega16 |
5 | ATmega161 ATmega162 ATmega163 ATmega164 ATmega169 |
6 | ATmega2560 ATmega2561 ATmega32 ATmega324 ATmega329 |
7 | ATmega3290 ATmega64 ATmega640 ATmega644 ATmega649 |
8 | ATmega6490 ATmega8515 ATmega8535 |
9 | Tiny Series |
10 | ATtiny12 ATtiny13 ATtiny15 ATtiny25 ATtiny26 |
11 | ATtiny45 ATtiny85 ATtiny2313 |
12 | Classic Series |
13 | AT90S1200 AT90S2313 AT90S2333 AT90S2343 AT90S4414 |
14 | AT90S4433 AT90S4434 AT90S8515 |
15 | AT90S8535 |
16 | CAN Series |
17 | AT90CAN128 |
18 | PWM Series |
19 | AT90PWM2 AT90PWM3 |
Hallo Anon Anon, Hier ist Marco aus dem Hackerspace, Edit : Betrifft anscheinend doch nur das Programmieren im Parallelmodus Habe mir mal das Datasheet des AT89S52 heruntergeladen und dort unter Punkt 4.10 EA/VPP folgendes gesehen: "This pin also receives the 12-volt programming enable voltage (VPP) during Flash programming" Würde daher darauf tippen, das er an den Pin 12V "Programierspannung" benötigt, wir hatten aber nur die 5V angelegt, eventuell hat er deshalb nur gelegentlich das Programm angenommen, die Fehlermeldung "Chip enable programming error" welche wir bekamen könnte eventuell dazu passen. Gruß Marco (lange5766) PS: bin ab ca 17:00 wieder im Space
:
Bearbeitet durch User
Hallo Anon Anon. Die 12V Programmierspannung braucht der Chip nur im Parallel-Programmiermodus. Wird seriell über SPI programmiert, braucht der Chip nur VCC (4V bis 5,5V). Ich habe jetzt auch probiert den 89S52 in mein Programmiergerät zu integrieren (ähnlich dem USBasp, mit selbstgeschriebener Software), aber der Chip zickt. Während der 89S8252 und 89S8253 tadellos zu programmieren sind, weigert sich der 89S52 beharrlich. Es sieht so aus, als wenn Chip und Datenblatt nicht zusammenpassen. Ich bekomme schon bei der Initialisierung des 89S52 einen falschen Rückgabecode. Laut Datenblatt sollte die Antwort (im Serial-Mode) auf "Programming Enable" der Code 0x69 sein, ich erhalte vom Chip aber 0x53 - wie es der 89S8252/53 machen. Im Parallel-Mode, in einem Programmiergerät, läßt sich der Chip anstandslos programmieren. Vermutlich haben wir das gleiche Problem. Ich werde mir die Sache mal näher ansehen und versuchen herauszufinden, was da schief läuft. Gruß. Tom
Ich habe mir gerade etwas von einem anderem 8051 Typen durch gelesen. Die io Ports stehen z.b. initial nur auf input, ein externes poweronreset ist nicht nötig usw..Das Datenblatt halte ich für den Schlüssel zum Erfolg.
Hallo allesamt, vielen Danke, dass ihr auch weiterhin alle versucht mir zu helfen. Marco L. schrieb: > Hier ist Marco aus dem Hackerspace, > > Edit : Betrifft anscheinend doch nur das Programmieren im Parallelmodus Hi Marco, witzig, dass du meinen Thread gefunden hast und cool, dass du dir noch mal Gedanken gemacht hast deswegen. Das mit den 12V hatten wir gestern auch kurz überlegt und dann im Datenblatt gefunden, dass es nur zum parallelen Programmieren gehörte. Aber da warst du glaube ich gerade beschäftigt. Ich denke diese Woche schaffe ich es wsl nicht wieder in den Hackerspace zu kommen, weil wir zuhause gerade am Umbauen sind. Aber danach mal gucken ;) TomA schrieb: > Während der 89S8252 und 89S8253 tadellos zu > programmieren sind, weigert sich der 89S52 beharrlich. Es sieht so aus, > als wenn Chip und Datenblatt nicht zusammenpassen. Hi Tom, was verwendest du dann für ein Programmiergerät für den 89S8252? Den hatte ich zuerst überlegt zu nehmen, hab damals aber keinen passenden Programmer gefunden. Das mit dem Datenblatt kann natürlich sein, allerdings müssten die Pins für den ISP und Reset generell ja eigentlich richtig sein, sonst hätte ich es ja wsl nicht geschafft gelegentlich ein Programm zu übertragen. Ich könnte mir allerdings vorstellen, das irgendein anderer Pin, den wir momentan nicht bedenken auf HIGH oder LOW gezogen werden müsste und da dieser sich undefiniert zwischen HIGH und LOW hin und her bewegt, die Schaltung gelegentlich murks macht. Falls du irgendwie bei dir Erfolg haben solltest beim Programmieren, dann sag mal bescheid ;) Matthias K. schrieb: > Ich habe mir gerade etwas von einem anderem 8051 Typen durch gelesen. > Die io Ports stehen z.b. initial nur auf input, ein externes > poweronreset ist nicht nötig usw..Das Datenblatt halte ich für den > Schlüssel zum Erfolg. Welchen 8051er, bzw. welches Datenblatt hast du denn gelesen ;) ?
Hallo Anon Anon. Ich benutze ein selbstgebautes Programmiergerät. Die Firmware ist eine modifizierte V-USB, die Software für den PC habe ich selbst geschrieben. Dadurch kann ich überprüfen, was bei der Kommunikation zwischen dem µC und dem PC so abläuft. Zur Kontrolle kann ich den µC aus der Schaltung nehmen und in einem Parallel-Programmer bearbeiten. Ich sehe daß das löschen des µC funktioniert. Aber weder programmieren, noch auslesen geht über SPI. Egal was ich mache, beim initialisieren kommt ständig der falsche Rückgabecode (0x53 statt 0x69). Habe schon bei ATMEL nachgesehen, ob sich an der Programmierung des Chips etwas geändert hat. Habe allerdings nichts gefunden. Meine Tests decken sich mit deinen Beobachtungen. Wenn der Kinamann, der deinen Programmer gemacht hat nur prüft, ob der Chip nicht 0xFF zurückgibt, dann ist der µC trotz falschem Rückgabecode für ihn ansprechbar. Und wenn er die geschriebenen Daten nicht zurückließt und vergleicht, dann glaubt er auch den Chip beschrieben zu haben. :( Nachdem ich den Chip initialisiere, bekomme ich den falschen Code zurück und schon das schreiben/lesen der ersten Flashzelle scheitert. Habe noch keine Ahnung woran es liegt. Gruß. Tom
... also ... ich beschäftige mich mit Microcontrollern der Serien MCS-51 (hier speziell den 89S52 und den 89C4051), AVR und dem (ARM) LPC1114... Die 51er Serie hab ich mal auf die Seite gelegt (schon eine Weile nicht mehr gemacht gehabt). Den USBasp konnte ich immer nur schwierig zur Zusammenarbeit mit den 89S52 bewegen und ich hatte mir einen eigenen Flasher gebaut gehabt (der "leider" zu nichts ausser zu mir selbst kompatibel ist). Peter Danneger hatte mir bzgl. des Verhaltens etwas geschrieben gehabt und zwar der Bedämpfung der Signale auf MISO-MOSI-CLK und deren übersprechen. Im ersten Anlauf hatte ich Darlingtontreiber zwischen die Leitungen geschaltet gehabt (mit denen mein eigener Flasher funktioniert hatte) und mußte mich (gerechterweise) belehren lassen, dass die Transistoren die Leitungen so bedämpfen dass es funktioniert, es aber einfache Reihenwiderstände in den Signalleitungen auch getan hätten. In: Beitrag "Stand-Alone ISP-Flasher für AT89S über RS232" hatte ich den ersten Flasher vorgestellt gehabt, der mittlerweile bis zur Version 3 gediehen war und da dann immer absolut Problemlos einen 89S52 flashen konnte. Allerdings hatte ich zur Vorsorge die "Standardresetschaltung" aus Widerstand, Kondensator und Diode über einen Jumper abtrennbar gemacht, damit die Controlle dem Flasher vorbehalten bleibt. Wenn du magst, kann ich dir einen programmierten AT89S2051 (das ist der Controller des Flashers) per Post zuschicken, damit du dir einen eigenen Flasher bspw. auf Lochrasterkarte oder Lochstreifenkarte aufbauen kannst (ob ich noch irgendwo eine unbestückte Platine rumliegen habe weiß ich nicht). Für diesen Flasher hatte ich eine Windowssoftware und eine Konsolensoftware geschrieben gehabt, die problemlos unter Win-XP, Vista und Win7 läuft (benötigt DotNet 4, bei Win7 bei der Installation schon dabei). Der Anschluß meines Flashers ist zwar "nur" mit einer seriellen Schnittstelle machbar, aber da ich kein "Bitbanging" gemacht habe, sondern die Codes einfach über die RS-232 verschicke, funktioniert jeder mir verfügbar USB2RS232 Adapter (die Chips hier waren FTDI, MCP-2200 und CP21xx). Wenn du magst, kann ich dir auch meinen Standardschaltplan für den 89S52 schicken. Prinzipiel allerdings würde ich dir (nach Peter Danneger) raten, in die Signalleitungen 150 Ohm Serienwiderstände einzubauen, da ich sehr annehme, dass dein USBasp sehr Flashfrequenz besitzt und von daher die Signale wohl übersprechen !!! Schaltplan der Version 3 (solltest du einen eigenen AT89S52 Flasher bauen wollen)... gibts im Anhang, Gruß, Ralph
... sorry, es sind 56 Ohm Serienwiderstände und nicht 150 Ohm !
Hallo Ralph. Die Reise scheint in die von dir angegebene Richtung zu gehen. Ich habe jetzt den 89S52 in eine andere Platine gesteckt. Diese Platine hat noch Treiberbausteine zwischen dem USB-Programmerchip und dem 89S52. In dieser Platine bekomme ich den korrekten Rückgabecode 0x69 und kann den Speicher des µC lesen. Programmieren klappt noch nicht, aber das ist vermutlich noch ein Fehler in meinem Programm. Werde an der anderen Platine mal die Serienwiderstände einbauen, mal sehen ob es was hilft. Gruß. Tom
Ich weiß nicht, ob es auch bei Deinem gilt, ich hab in einem Datenblatt vom AT89LP2052_4052 gelesen. Mein Programmer ist einer von Reichelt, da gibt es auch Infos zu. Leider bin ich noch nicht dazu gekommen, das zu benutzen. Im Plan ist ein Controller gesteuerter Step-Down converter für Spannungen bis 0 V und starke Ströme. Aber das heisst erst mal noch nichts.
Anon Anon schrieb: > aah okay.. > das scheint noch ein anderer Programmer zu sein als meiner. > Der den du da hast, der unterstützt allerdings auch die 8051er serie > nicht : > Supported microcontrollers include: > Mega Series > ATmega8 ATmega48 ATmega88 ATmega168 ATmega328 ... Doch, bei meinem stand es dabei, ich hatte obigen nur als Beispielfoto gebracht. Nun habe ich mal ein altes Testboard vom Equinox Programmer ausgegraben. Als Programmer wurde vor 15 Jahren nur der für AVR gekauft, da alles recht teuer war. Mit dem Umstecken von 2 Jumper kann man da die alten AVR als auch einige 89XX programmieren. Als AVR gehen mit dem Programmer 90S2313, 90S8515 und sicher weitere. Also ist prinzipiell die Technik i.O. Komischerweise geht ein 89S51. Aber ein 89S8252 geht nicht. Und einen 89C2051 kann ich im Menue gar nicht anwählen. Wenn ich etwas anklicke, springt es immer wieder auf 89S2051? Natürlich auch nicht mal auslesen. Gibt es noch andere Programme als das progisp ?
Michael_ schrieb: > Und einen 89C2051 kann ich im Menue gar nicht anwählen. Der 89C2051 ist KEIN ISP-Controller, dieser kann nur parallel programmiert werden !!!!
Hallo nochmal, vielen Dank für eure Tipps, denn jetzt funktioniert es. Der Schlüssel zum Erfolg war tatsächlich die 56 Ohm Widerstände, die ich in Reihe zwischen jedes Kabel des Programmers und dem Pin des µC geschaltet habe. Übersprechen scheint hier also tatsächlich das Problem gewesen zu sein. Von daher jetzt schon mal ein ganz ganz großes Dankeschön an alle die geholfen haben. Und vorallem für die finalen Tipps von Ralph S. schrieb: > Prinzipiel allerdings würde ich dir (nach Peter Danneger) raten, in die > Signalleitungen 150 Ohm Serienwiderstände einzubauen, da ich sehr > annehme, dass dein USBasp sehr Flashfrequenz besitzt und von daher die > Signale wohl übersprechen !!! Hi Ralph, meintest du eine sehr HOHE oder sehr NIEDRIGE Flashfrequenz? Das Wort hast du nämlich anscheinend vergessen. Mich würde nämlich der elektrische Hintergrund interessieren warum es jetzt klappt. Hab ich es richtig verstanden, dass durch die (hohe oder niedriege?) Flashfrequenz ein so starkes Magnetfeld in den Anschlussleitungen des Programmers entsteht, dass dieses in der danebenliegenden Leitung wieder eine Spannung induziert und dann ein Übersprechen auftritt??? Und haben die Widerstände nun einfach den Effekt, dass das Magnetfeld kleiner oder weniger stark gehalten wird? Außerdem würden mich noch interessieren, da ich keine 56 Ohm Widerstände sondern nur 47 und 100 Ohm zur Verfügung hatte, welche nun theoretisch besser wären. (Die 47 Ohm Widerstände funktionieren ja momentan) Ralph S. schrieb: > Wenn du magst, kann ich dir einen programmierten AT89S2051 (das ist der > Controller des Flashers) per Post zuschicken, damit du dir einen eigenen > Flasher bspw. auf Lochrasterkarte oder Lochstreifenkarte aufbauen kannst > (ob ich noch irgendwo eine unbestückte Platine rumliegen habe weiß ich > nicht). > > Für diesen Flasher hatte ich eine Windowssoftware und eine > Konsolensoftware geschrieben gehabt, die problemlos unter Win-XP, Vista > und Win7 läuft (benötigt DotNet 4, bei Win7 bei der Installation schon > dabei). ... Ralph S. schrieb: > Wenn du magst, kann ich dir auch meinen Standardschaltplan für den 89S52 > schicken. An deiner Schaltung bin ich übrigens trotzdem interessiert, bzw. an der Software und an dem Standardschaltplan. Einen USB-RS232-Umsetzter habe ich nämlich zu hause. Wäre echt cool, wenn du mir das zukommen lassen könntest :) Den µC und Porto und so würde ich dir dann natürlich auch bezahlen. TomA schrieb: > Wenn der Kinamann, der > deinen Programmer gemacht hat nur prüft, ob der Chip nicht 0xFF > zurückgibt, dann ist der µC trotz falschem Rückgabecode für ihn > ansprechbar. Und wenn er die geschriebenen Daten nicht zurückließt und > vergleicht, dann glaubt er auch den Chip beschrieben zu haben. :( Damit ist dann wohl auch erklärt, warum die Software gelegentlich glaubte, den µC programmiert zu haben :)
Was ich gerade noch mal erwähnen wollte. Mein µC ist nun zwar erreichbar und auch programmierbar, allerdings gibt es gelegentlich Übertragungsfehler beim Programm. In diesem Fall waren dann meist nur einzelne Bytes falsch übertragen worden und es half folgendes: 1. "Erase Chip" aufrufen 2. Danach stürzt der µC dann meist ab und es gibt erneut den "Chip-Enable-Programm-Error" 3. Um das zu beheben, Versorgungsspannung (Netzteil und Programmer) entfernen und wieder reinstecken 4. Manuell einen Reset auslösen (RST-Pin des µC per Kabel mit Plus verbinden) 5. Nochmal programmieren Mit diesem Zustand bin ich zwar absolut zufrieden, allerdings frage ich mich trotzdem warum es gelegentlich zu Übertragungsfehlern kommt. Liegt das evlt. an meinen 47 Ohm Widerständen (statt den 56 Ohm)?
Smile, ich meinte eine sehr hohe Frequenz (sorry)... Übersprechen geschieht aus viellerlei Gründen und EIN Grund dafür ist, dass 2 nebeneinanderliegende Leitungen auf die Länge gesehen einen Kondensator bilden. Ein Kondensator ist für hohe Frequenzen "durchlässig". Das Übersprechen war auch der Grund dafür, dass die Flachbandleitungen "damals" bei IDE Festplatten mit UDMA und 100 MHz abwechselnd Signalleitung - Masseleitung - Signalleitung hatten ...
Ralph S. schrieb: > Der 89C2051 ist KEIN ISP-Controller, dieser kann nur parallel > programmiert werden !!!! Stimmt ja, ich hatte mindestens gedacht, das man den auslesen kann. Nun hab ich mich schon gefreut, das Problem gelöst zu haben. Mein TOP2005 Programmer kann ja die prinzipiell auch brennen. Meine 89Cxx und 89Sxx werden erkannt. Jedoch werden die 89C2051 als leer erkannt, obwohl sie garantiert beschrieben sind. Kann das so sein, wenn die geschützt sind? Leider hab ich keine Ahnung von 51-Programmierung, keinen Assembler usw. um ein Testprogramm zu schreiben. Wäre jemand so nett, ein kleines Testprogramm als fertiges .bin-File hochzuladen, wo auf P1.0 - P1.7 eine LED blinkt. Da könnte ich mal das Brennen testen. Vorhandene Chip: 89C2051, 89S51, 89S8252 Danke!
Michael_ schrieb: > Wäre jemand so nett, ein kleines Testprogramm als fertiges .bin-File > hochzuladen, wo auf P1.0 - P1.7 eine LED blinkt. Ich hab mal nen Code-Schnipsel ausm Internet erweitert, bei einer Taktfrequenz von 22.1184 MHz sollte die LED(auf Port P1.0) ca. jeweils immer im Rythmus von 1 Sekunde an und aus gehen. Sollte jetzt unter deinem AT89S51 laufen. Die Datei ist im Anhang ;)
1 | $include(reg515c.inc) |
2 | main: setb p1.0 |
3 | mov r2,#100 |
4 | call dly1second |
5 | clr p1.0 |
6 | mov r2,#100 |
7 | call dly1second |
8 | jmp main |
9 | |
10 | dly1second: |
11 | call delay |
12 | djnz r2,dly1second |
13 | ret |
14 | |
15 | ;delay for a number of ms (specified by acc) |
16 | delay: |
17 | mov r0, #10 |
18 | dly2: mov r1, #230 |
19 | dly3: nop |
20 | nop |
21 | nop ;6 NOPs + DJNZ is 4.34 us |
22 | nop ;with the 22.1184 MHz crystal |
23 | nop |
24 | nop |
25 | djnz r1, dly3 ;repeat 230 times for 1 ms |
26 | djnz r0, dly2 ;repeat for specified # of ms |
27 | ret |
So, hab ich mir die Mühe gemacht, die Dokumentation "etwas" zu überarbeiten (an die Version 3). Findest du hier im Anhang... ebenso wie die Windowsprogramme die den Flasher steuern. Einen 89C2051 habe ich auch geflasht, wenn du mir per PN deine Adresse hinterlässt, schick ich dir einen bereits geflashten Controller mit dem du einen 89S52 - Flasher aufbauen kannst ! Gruß, Ralph
Die PDF wurde nicht hochgeladen ... deshalb noch mal !
Ralph S. schrieb: > o, hab ich mir die Mühe gemacht, die Dokumentation "etwas" zu > überarbeiten (an die Version 3). > > Findest du hier im Anhang... ebenso wie die Windowsprogramme die den > Flasher steuern. > > Einen 89C2051 habe ich auch geflasht, wenn du mir per PN deine Adresse > hinterlässt, schick ich dir einen bereits geflashten Controller mit dem > du einen 89S52 - Flasher aufbauen kannst ! Vielen vielen Dank :) Echt super :) du hast eine PN
Anon Anon schrieb: > Ich hab mal nen Code-Schnipsel ausm Internet erweitert, bei einer > Taktfrequenz von 22.1184 MHz sollte die LED(auf Port P1.0) ca. jeweils > immer im Rythmus von 1 Sekunde an und aus gehen. Dank erstmal! Brauch ich unbedingt die Taktfrequenz? Ich habe jetzt 8 MHz. Ich möchte nur, das das Programm auch praktisch angekommen ist. Also das berühmte "Hallo". Ich hab heute noch mal mit meinem China-Programmer experimentiert. Nur ein Board angeschlossen, wo der Takt dran ist, sonst nichts. Der 89S51 geht, der 89S8252 geht aber immer noch nicht.
Bei der Datenblattsuche bin ich auf ein Errata Sheet zu den 89S8252 ... gestoßen. Für ISP steht da was von einer "Zacke" auf SCK. Vielleicht ist das die Ursache beim programmieren.
Bitte 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.