Forum: Mikrocontroller und Digitale Elektronik Probleme bei Grundbeschaltung 8051 (AT89S52)


von Anon A. (anon1234)


Angehängte Dateien:

Lesenswert?

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

von Anon A. (anon1234)


Angehängte Dateien:

Lesenswert?

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

von Georg G. (df2au)


Lesenswert?

Mach mal den 10uF Kondensator am Reset drastisch kleiner, 0.1uF als 
Test.

: Bearbeitet durch User
von Michael_ (Gast)


Lesenswert?

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.

von Martin (Gast)


Lesenswert?

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?

von Anon A. (anon1234)


Lesenswert?

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

von TomA (Gast)


Lesenswert?

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

von DingsDa (Gast)


Lesenswert?

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.

von Anon A. (anon1234)


Lesenswert?

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 :)

von Michael_ (Gast)


Lesenswert?

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.

von TomA (Gast)


Lesenswert?

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

von Anon A. (anon1234)


Lesenswert?

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.

von Michael_ (Gast)


Lesenswert?

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

von Anon A. (anon1234)


Lesenswert?

: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

von TomA (Gast)


Lesenswert?

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

von Georg G. (df2au)


Lesenswert?

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.

von TomA (Gast)


Angehängte Dateien:

Lesenswert?

@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

von Michael_ (Gast)


Lesenswert?

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.

von Anon A. (anon1234)


Lesenswert?

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

von Bernd N (Gast)


Lesenswert?

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.

von Amateur (Gast)


Lesenswert?

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.

von Georg G. (df2au)


Lesenswert?

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.

von Michael_ (Gast)


Lesenswert?

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.

von Anon A. (anon1234)


Lesenswert?

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

von Michael_ (Gast)


Lesenswert?

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?

von Anon A. (anon1234)


Lesenswert?

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)

von Anon A. (anon1234)


Lesenswert?

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??

von Anon A. (anon1234)


Angehängte Dateien:

Lesenswert?

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/

von Michael_ (Gast)


Lesenswert?

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.

von Anon A. (anon1234)


Lesenswert?

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

von Marco L. (lange5766)


Lesenswert?

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
von TomA (Gast)


Lesenswert?

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

von Matthias K. (kannichauch)


Lesenswert?

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.

von Anon A. (anon1234)


Lesenswert?

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 ;) ?

von TomA (Gast)


Lesenswert?

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

von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

... 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

von Ralph S. (jjflash)


Lesenswert?

... sorry, es sind 56 Ohm Serienwiderstände und nicht 150 Ohm !

von TomA (Gast)


Lesenswert?

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

von Matthias K. (kannichauch)


Lesenswert?

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.

von Michael_ (Gast)


Lesenswert?

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 ?

von Ralph S. (jjflash)


Lesenswert?

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 !!!!

von Anon A. (anon1234)


Lesenswert?

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 :)

von Anon A. (anon1234)


Lesenswert?

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)?

von Ralph S. (jjflash)


Lesenswert?

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 ...

von Michael_ (Gast)


Lesenswert?

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!

von Anon A. (anon1234)


Angehängte Dateien:

Lesenswert?

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

von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

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

von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

Die PDF wurde nicht hochgeladen ...

deshalb noch mal !

von Anon A. (anon1234)


Lesenswert?

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

von Michael_ (Gast)


Lesenswert?

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.

von Michael_ (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.