Archiv verlassen und diese Seite im Standarddesign anzeigen : (Mir) unerklärliches AVR-Sterben
Moin!
Ich habe eine simple Schaltung auf Basis eines mega168 aufgebaut. Das anhängende Schaltbild (ganz unten) zeigt das Wesentliche, nicht mit dargestellt sind nur ein FT232RL (an den Signalen TXD_FT232 und RXD_FT232) und ein synchron serieller DAC (an den Signalen DOUT und PD_SCK). Die Teile funktionieren (s.u.), ich habe sie hier einfach aus Platzgründen weggelassen. Das LCD verfügt über einen KS108 kompatiblen Controller. Sorry übrigens für das etwas pfuschige Schaltbild, hab's auf die Schnelle zusammengehauen ...
Die Schaltung ist in SMD auf einer ordentlichen Platine aufgebaut.
Ich habe nun zum zweiten Mal folgendes Problem:
nach dem Aufbau funktioniert zunächst alles einwandfrei (LCD, UART, DAC), sodass ich mit der eigentlichen Firmwareentwicklung beginnen kann. Nach etwa dem 20. Flashen (sehr grob geschätzt) häufen sich Fehler beim Verifizieren nach dem Flashen, und die Firmware läuft auch folgerichtig nicht wie sie soll. Nach einigen weiteren Flash-Vorgängen treten dann jedesmal Fehler beim Verifizieren auf, ich kann den Controller also effektiv nicht mehr flashen. Ein paar Mal kann ich dann immerhin noch die Device Kennung auslesen, bis das dann auch nicht mehr geht. Ich flashe idR aus BASCOM, habe testweise auch mit AVRDUDE geflasht und dabei zwei verscheidene ISP Dongles getestet (USBASP und USBtinyISP) - mit dem gleichen Ergebnis.
in AVRDUDE
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
in BASCOM
Could not detect chip, Auto program failed
Chip ID: FFFFFF
Mit den Dongles kann ich andere AVRs problemslos flashen (Positivkontrolle). Wenn ich mir ansehe, was auf dem ISP nach dem Defekt los ist, fällt auf, dass RESET, SCK und MOSI tun was sie sollen (auf den ersten Blick, habe mir den Bitstrom nicht genauer angesehen) aber MISO permanent auf low bleibt. Ich habe mal den Eingangswiderstand von allen ISP Pins am Controller nach Masse gemessen, die sind alle um die 10k, MISO hat also zumindest keinen Schluss nach Masse. Außerdem habe ich die Pins vom ISP, die das LCD parallel nutzt, vom LCD getrennt, das hat dann auch nichts mehr geändert (zu dem Problem siehe unten).
Was mich stutzig macht ist, dass ich das exakt gleiche "Todes-Szenario" jetzt zum zweiten Mal habe. D. h. ich habe den ersten Controller wieder von der Platine runtergefönt und einen neuen draufgesetzt und von vorne angefangen - wie gesagt, mit dem gleichen Ausgang, erst geht alles, dann ist das Flashen nur noch sporadisch erfolgreich, bis der Controller dann schließlich augenscheinlich tot ist.
Wie man sieht, nutze ich die ISP Pins auch für's LCD. Ich weiß, dass Application Note AVR910 für diesen Fall empfiehlt, Peripherie am ISP durch Widerstände zu "entkoppeln". Das habe ich mir hier in der Tat gespart, weil ich noch nie Probleme dieser Art hatte. Okay, das mag ein Fehler sein, aber: Selbst wenn diese Doppelnutzung zu Schreibfehlern beim Flashen führen sollte, kann ein Controller dadurch hardwaremäßig Schaden nehmen? Kann ich ihn also "kaputtflashen"? Können dabei die Fusebits vielleicht total verdreht werden?
Sorry für die vielen Worte, hat jemand vielleicht eine Idee, wo das Problem liegen könnte? Im Moment steht nur auf meiner Liste, beim nächsten Mal Widerstände zwischen LCD und ISP-Pins einzubauen. Bin ansonsten mit meinem Latain gerade etwas am Ende ...
Ganz vielen Dank!
Malte
29120
Hallo!
Sorry für die vielen Worte, hat jemand vielleicht eine Idee, wo das Problem liegen könnte? Im Moment steht nur auf meiner Liste, beim nächsten Mal Widerstände zwischen LCD und ISP-Pins einzubauen. Bin ansonsten mit meinem Latain gerade etwas am Ende ...
Ich würde zuerst einen mega168 genauso flaschen ohne ihn danach mit der o.g. Schaltung zu verbinden um die Quelle der wachsender Menge vom Fehlern eindeutig zu finden.
oberallgeier
27.09.2014, 12:07
... Sorry für die vielen Worte, hat jemand vielleicht eine Idee, wo das Problem liegen könnte? ...Genaugenommen habe ich keinen Peil dazu. ABER ich hatte mal (ich erinnere mich ungern und sehr dunkel daran) ähnliches erlebt. Hatte den (die!) Controller dann "ausserhalb" jeglicher Beschaltung getestet und für gut befunden und danach die Platine nachgebessert. Was im Einzelnen war, weiß ich nicht mehr.
Hallo!
Vielen Dank für's Mitdenken!
Ich würde zuerst einen mega168 genauso flaschen ohne ihn danach mit der o.g. Schaltung zu verbinden um die Quelle der wachsender Menge vom Fehlern eindeutig zu finden.
Hatte den (die!) Controller dann "ausserhalb" jeglicher Beschaltung getestet und für gut befunden und danach die Platine nachgebessert.
Die Controller sind in SMD Bauform, insofern ist schnelles "woanders" flashen nicht ganz so einfach. Vor allem glaube ich, dass das auch nicht der Punkt ist: ich konnte sie ja zunächst erfolgreich in der Zielschaltung programmieren, sie liefen dort ja - zunächst - einwandfrei. Mich wundert vor allem das "graduelle Sterben", also dass ich erst noch hin und wieder erfolgreich flashen kann, dann nicht mehr flashen kann, aber zunächst noch die device signature lesen, bis auch dieses nach einigen Lesevorgängen nicht mehr geht und der Controller dann offenbar ganz tot ist. Hat jemand speziell dazu eine Idee?
Gruß
Malte
Besserwessi
27.09.2014, 17:14
Kann es sein, dass die Spannungsversorgung nicht in Ordnung ist, und der Regler Zeitweise schwingt ? Das könnte den µC eventuell beschädigen, auch wenn zumindest die alten recht robust gegen Überspannung waren (wurde heiß, gingen nach dem Abkühlen oft aber wieder).
Möglich wäre ggf. noch das die Schaltung irgendwie Empfindlich auf ESD reagiert, entweder über die Taster oder ähnliches, oder auch einfach bei Verbinden des ISP Programmers. Ein Problem könnte ggf. auch Fehler (Unterbrechung) bei der Platine sein, so dass viel Strom zwischen den GND oder VCC Anschlüssen fließen kann - auch damit kriegt man den µC ggf. kaputt.
Beim Plan fehlt noch der Abblockkondensator am VCC Anschluss für den analogen Teil. Da sollte normal keine echtes Problem sein, könnte aber unter ungünstigen Bedingungen dafür sorgen das der Brownout Detektor zu früh anspricht, und damit ggf. den µC lahm legt.
schorsch_76
27.09.2014, 17:20
Wie schaut die Betriebsspannung aus? Mach mal ein Scope mit einem Oszi....
Die Reset Schaltung gefällt mir nicht ... Schau dir dazu das Hardware Design Appnote von Atmel an ... [1] Seite 6. Ich hab es so ausgeführt.
Reset Schaltung:
29124
Ist die Peripherie sicher auch auf TTL Pegel?
Ziehen irgendwelche Bauteile mehr als die Pins hergeben können? (max. 20 mA).
Ist die gesamt abgegebene Leitung des Atmega in grünen Bereich?
Ist das Display ein TTL Typ oder etwa eine 3.3V Variante? dann könnte zu viel Strom fliessen ...
Pin 4 und Pin 6 brauchen jeweils eigene 100nF Stützkondensatoren.
Avcc braucht auch einen eigenen Stützkondensator.
Erzeugung +5V:
29125
[1] http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_application-note_avr042.pdf
@ malthy
Ich wundere mich nur, das du für Entwicklung einen µC in SMD nimmst, wenn es gleichen in DIL gibt. :confused:
Hallo!
Danke für die Hilfe!
Die Versorgungsspannung sieht okay aus, ich wüsste auch erstmal nicht, wo es da haken könnte. Die Erzeugung der 5V ist 08/15 folgendermaßen realisiert:
29126
Der Gleichrichter dient nur als Verpolungsschutz, deswegen fällt die Siebung nur minimal aus. Allerdings speise ich die Versorgungsspannung im Moment noch hinter dem Gleichrichter ein, damit alles auf der Masse von meinem Netzteil liegt. Hier mal schnell ein Einblick in die Versorgungsspannung, AC-gekoppelt, 20 mV/div. Vpp ist ca 57 mV, Vrms 8.44 mV. Sieht für mich erstmal okay aus (zumal auf die Schnelle gemessen mit frei fliegenden Kabeln). Die Schaltung zieht insgesamt ca. 80 mA, was natürlich im wesentlichen auf die Hintergrundbeleuchtung des LCDs zurückgeht.
29127
Stimmt schon, AVCC ist etwas ruppig angeschlossen, ich benutze hier den gesamten Analogteil des µC nicht, aber ich werde das beim nächsten mal ordentlicher machen. Dass die Sache daran scheitert glaube ich aber erstmal auch nicht.
Auch die Beschaltung vom Reset ist etwas minimal ausgefallen, aber nach den Diskussionen die ich um dieses Thema bisher so verfolgt habe, sei das bei den neueren AVRs auch nicht mehr so ein riesen Problem, deswegen habe ich den Pull-Up weggelassen. Okay, auch das kann ich besser machen. Aber auch da bin ich erstmal ein wenig skeptisch dass dort das Problem liegt, denn der Punkt ist ja, dass ich nicht einfach nur eine "Funktionsstörung" habe sondern tatsächlich irgend ein letaler Effekt auftritt.
Das LCD habe ich als 5V Typ in China gekauft - muss also nicht zwingend stimmen, bin da aber erstmal nicht vom Gegenteil ausgegangen. Und die Gesamtstromaufnahme vom System liegt in einem realistischen Bereich (s.o.).
Gruß
Malte
- - - Aktualisiert - - -
Ich wundere mich nur, das du für Entwicklung einen µC in SMD nimmst, wenn es gleichen in DIL gibt. :confused:
:-) Also erstens macht mir der Umgang mit SMD Spass, also rein handwerklich. Ist halt nichts für Weicheier ;-) ... nein im Ernst, tatsächlich ist der Umgang damit garnicht so schlimm wie man als Anfänger vielleicht erstmal denkt. Zumindest mir ging es so, und ich war dann überrascht wie gut man damit zurecht kommt. Aber dann gibt es noch technische Gründe. Die Aufbauten werden deutlich kleiner, das ist zunächst ein finanzieller Vorteil, wenn man Platinen machen lässt. Wenn man seine Schaltungen in Gehäuse o.ä. einbauen will, ist es außerdem angenehm, wenn man nicht so riesige Bretter hat, sondern eine kleine flache Platine. Im übrigen gibt es viele moderne ICs eh nur noch in SMD, wenn ich also schon einige Bauteile in SMD auf der Platine habe, dann brauche ich den Rest auch nicht mehr in DIP machen, finde ich. War jetzt etwas off topic ... :-)
Gruß
Malte
schorsch_76
27.09.2014, 18:10
Ich hab auch schon SMD Versionen verbaut. Auch Atmega168p. Hab immer alle Stütz - C verbaut.... Egal ob ich den Analogteil benutzt habe oder nicht. Ich und du kennen den internen Aufbau des IC's nicht. Sicher bist du nur, durch einhalten des Datasheet.Es gilt halt oft die Regel: "Premature Optimization is the root of all evil!". Auch beim sparen von 100nF C's ....
IC's sterben halt durch überschreiten der Spezifikationen ... Induktionsspannungen .... Strombegrenzung ... Ptot ... Temperatur...
Die CS-Pins vom LCD brauchen dringend Pull-ups, damit die Datenleitungen beim Flashen auch abgeschaltet werden. Beim RESET reicht üblicherweise auch schon ein Pull-up ohne Kondensator.
Außerdem ist ein 10µF Kondensator nach dem Gleichrichter ein bisschen wenig.
schorsch_76
27.09.2014, 18:42
Hier stehts im Design Guide. Deine fehlenden Stütz Cs sind das Problem in Verbindung mit dem 8Bit Mode ...
Digital supply
Looking at the datasheet for an Atmel AVR microcontroller, one can be fooled to believe that power supply is not critical.
The device has a very wide voltage range, and draws only a few mA supply current. But as with all digital circuits, the
supply current is an average value. The current is drawn in very short spikes on the clock edges, and if I/O lines are
switching, the spikes will be even higher. The current pulses on the power supply lines can be several hundred mA if all
eight I/O lines of an I/O port changes value at the same time. If the I/O lines are not loaded, the pulse will only be a few
ns.
This kind of current spike cannot be delivered over long power supply lines; the main source is (or should be) the
decoupling capacitor.
Sicher bist du nur, durch einhalten des Datasheet.Es gilt halt oft die Regel: "Premature Optimization is the root of all evil!".
Ich wollte auch garnicht grundsätzlich widersprechen. Mir geht's erstmal nur um eine Abschätzung von Wahrscheinlichkeiten wo das Problem liegen mag.
Wie ist denn die Eure Meinung zu der nicht vorhandenen "Entkopplung" des LCDs von den ISP Pins durch Widerstände? Kann das so fatale Folgen haben? Ich kann das auch nicht recht glauben, habe das nämlich ehrlich gesagt schon relativ häufig genau so gemacht, also KS108 Datalines mit ISP doppelt genutzt. Bisher ohne Probleme ...
Vielleicht habe ich auch wirklich nur unglaubliches "Glück" gehabt und zweimal in Folge den gleichen defekt durch ESD erzeugt. Wie ist die Tatsache zu beurteilen, dass der Controller nicht schlagartig ausgefallen ist, sondern mehr und mehr Probleme mit dem Flashen aufgetreten sind?
Gruß
Malte
- - - Aktualisiert - - -
Hier stehts im Design Guide. Deine fehlenden Stütz Cs sind das Problem in Verbindung mit dem 8Bit Mode ...
Okay, sorry, dann habe ich Dich nicht ganz richtig verstanden. An welcher Stelle fehlen Deiner Ansicht nach Cs? Direkt am µC habe ich nur einen 100 nF, alle anderen ICs in der Schaltung haben auch welche. Du meinst ich sollte unmittelbar am LCD noch welche vorsehen? Oder mehr Kapazität(en) am Controller vorsehen?
Die CS-Pins vom LCD brauchen dringend Pull-ups, damit die Datenleitungen beim Flashen auch abgeschaltet werden.
Das ist auch nochmal ein guter Punkt. Danke!
Außerdem ist ein 10µF Kondensator nach dem Gleichrichter ein bisschen wenig.
Okay, das lässt sich auch leicht ändern.
Danke!
Malte
oberallgeier
27.09.2014, 18:57
... Wie ist denn die Eure Meinung zu der nicht vorhandenen "Entkopplung" des LCDs von den ISP Pins durch Widerstände ...Hmmmm. Ich war da immer kritisch. Habe aktuell auf mehreren Platinen mega1284er eingesetzt:
// ####>>>> Initialisierung der Anschlüsse für R5M auf mega1284: <<<<####
// PORTB vorzugsweise PB0 1 A E 40 PA0, Audi-Busy (vgl. hier auch)
// für LCD PB1 2 A E 39 PA1, Audi-Clock (MOSI, MISO und)
// PB2 3 E E 38 PA2, Audi-Data ( SCK )
// PB3 4 A E 37 PA3
// PB4 5 A EU 36 PA4
// MOSI, PB5 6 A E 35 PA5, ADC Batterie_2-Test (Test, Poti)
// MISO, PB6 7 AU E 34 PA6, ADC Batterie_1-Test !!RNCntrl!!
// SCK, PB7 8 A E 33 PA7
// /RESET 9 32 AREF ref Vcc, aktuell (?)
// - - - - - - - - - - - - - - -
// ####>>>> Initialisierung/Anschlüsse von PORT B für LCD DEM 16x2
// data bit 4 PB0 0 A WS Pin1 |
// data bit 5 PB1 1 A Pin2 | -- Der 10-polige Wannenstecker
// data bit 6 PB2 2 A Pin3 | ist an die Belegung
// data bit 7 SCK, PB3 3 A Pin4 | des Transitortester angepasst
// RS line PB4 RS Pin5 | es kommen noch
// ENABLE line MOSI, PB5 EN1 Pin6 | Pin 9 GND und
// R/W (offen) MISO, PB6 R/W Pin7 | Pin 10 Vcc dazu
// NC (TasteC) SCK, PB7 NC Pin8 |___________________________
// GND Pin9
// Vcc Pn10 | Anmerkg: ENABLE line !
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
bei denen das LCD am Port B hängt - und genau da sind die ISP-Anschlüsse. Ist ein einfaches LCD, 2x16, vierbittige Ansteuerung, kein GrafikLCD. OHNE jegliche "Entkopplung". Und völlig störungsfrei zu flashen. Keine Störungen des LCDs im Betrieb. Mehr kann ich nicht schreiben.
Hubert.G
27.09.2014, 19:17
Ich wollte auch garnicht grundsätzlich widersprechen. Mir geht's erstmal nur um eine Abschätzung von Wahrscheinlichkeiten wo das Problem liegen mag.
Ich denke das es der falsche Weg ist bei einem Prototypen mit Abblock-C zu sparen. Es ist sicher einfacher im nachhinein einige C wegzulassen als sich zu überlegen wo denn einer fehlen könnte.
Es fehlen auch die C vor und nach dem Spannungsregler, Elko als Ersatz sind nicht geeignet. Der Vorwiderstand für die Hintergrundbeleuchtung ist hoffentlich im LCD eingebaut.
Ich denke das es der falsche Weg ist bei einem Prototypen mit Abblock-C zu sparen. Es ist sicher einfacher im nachhinein einige C wegzulassen als sich zu überlegen wo denn einer fehlen könnte.
Wo liest Du raus, dass ich das zu irgend einem Zeitpunkt wollte? Mich würde interessieren wo Cs fehlen. Okay, der an AVCC ist sinnvoll, den ergänze ich. Wo noch?
Es fehlen auch die C vor und nach dem Spannungsregler, Elko als Ersatz sind nicht geeignet
Das sind Tantals. Habe ich oft so gesehen. Aber auch da werde ich KerKos ergänzen.
Der Vorwiderstand für die Hintergrundbeleuchtung ist hoffentlich im LCD eingebaut.
Ja.
schorsch_76
27.09.2014, 20:05
Pin 4 und Pin 6 brauchen jeweils eigene 100nF Stützkondensatoren.
Avcc braucht auch einen eigenen Stützkondensator.
Bei dir ist 4 und 6 mit einem C geblockt.
Auch wie Hubert schrieb: Block C's im Netzteil fehlen auch. Siehe mein Bild...
https://www.roboternetz.de/community/attachment.php?attachmentid=29125&d=1411834541
Bei Pin 4, 6 und Avcc möglichst nahe am µC ... den Stütz C anbringen. Leitungen sehr kurz halten.
Pin 4 und Pin 6 brauchen jeweils eigene 100nF Stützkondensatoren.
Naja, so dramatisch ist das jetzt auch wieder nicht, die Pins liegen auch unmittelbar nebeneinander. Bei manchen Sachen die man so in den Foren sieht kann man sich nur nur wundern das dieses überhaupt funktioniert, da gibt es viel schlimmeres.
schorsch_76
27.09.2014, 20:59
Siehe Design Guide..
https://www.roboternetz.de/community/threads/65733-%28Mir%29-unerkl%C3%A4rliches-AVR-Sterben?p=605592&viewfull=1#post605592
Generally, the Atmel AVR devices where power and ground lines are placed close together (like the Atmel
ATmega8535) will get better decoupling than devices with industry standard pin-out (like the Atmel ATmega8515),
where the power and ground pins are placed in opposite corners of the DIP package. This disadvantage can be
overcome by using for example a TQFP package, which allows decoupling capacitors to be placed very close to the die.
For devices with multiple pairs of power and ground pins, it is essential that every pair of pins get its own decoupling
capacitor.
The main supply should also have a tantalum or ceramic capacitor of some μF to stabilize it.
http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_application-note_avr042.pdf
Siehe Design Guide..
.
For devices with multiple pairs of power and ground pins, it is essential that every pair of pins get its own decoupling
capacitor.
.
Du meinst also, "essential" erklärt ein langsames Sterben eines ICs? Oder überhaupt ein Sterben eines Chips?
In gefühlten tausend Threads habe ich gelesen:
"Da fehlen Abblocks C ..."
weiter gehts dann:
"Hab sie eingebaut, geht trotzdem nicht ..."
Das Fehlerbild fehlender Cs passt weder zu "geht garnicht" noch zu "stirb langsam" und auch nicht zu "geht kaputt", obwohl man sich natürlich ein Szenario ausdenken kann, das irgendwie das Sterben eines ICs durch fehlende Abblock-Cs an diesem Chip erklären könnte. Damit will ich nicht sagen, daß man Abblocks-Cs vernachlässigen soll, aber sie erklären nicht jedes Problem.
Für mich erscheint die gemeinsame Nutzung von Pins durch ISP und LCD verdächtig, insbesondere weil sich der Defekt des µCs beim Programmieren zeigt. Wie sehen denn die ISP-Signale aus, wenn sich der Chip nicht programmieren läßt? Geht er doch noch, wenn man das LCD abtrennt? In dieser Richtung würde ich weiter forschen.
MfG Klebwax
schorsch_76
28.09.2014, 06:09
"Essential" ist ein recht starkes Wort bei den Anforderungen. "Should" wäre etwas deutlich schwächeres Wort....
For devices with multiple pairs of power and ground pins, it is essential that every pair of pins get its own decoupling
capacitor.
--------
Für Geräte mit multiplen Leistungs und Masse Pins, ist es essentiel dass jedes Paar von Pins seinen eigenen Entkoppelkondensator besitzt.
vs.
Für Geräte mit multiplen Leistungs und Masse Pins, ist sollte jedes Paar von Pins seinen eigenen Entkoppelkondensator besitzten.
Das sind doch zwei ganz andere Bedeutungen dieser Anforderung. Wir haben die erste Anforderung. Wäre ein "should" im Satz wäre die Anforderung deutlich schwächer....
http://www.duden.de/rechtschreibung/essenziell
Synonyme zu essenziell
ausschlaggebend, bedeutend, bedeutsam, bedeutungsvoll, belangreich, belangvoll, entscheidend, gewichtig, schwerwiegend, von Bedeutung/Belang, wesentlich, wichtig; (bildungssprachlich) relevant, signifikant, substanziell, von Relevanz
wesenhaft, wesensmäßig; (Philosophie) substanziell; (besonders Philosophie) essenzial
lebensnotwendig, lebenswichtig
Essentiel, legt schon ein sehr starkes Gewicht auf diese Anforderung.....
Wissen, warum dieser AVR stirbt, tu ich auch nicht. Ich zeige nur, was mir auffällt und mir als wichtig erscheint ...
*Kaffee schlürf*
Gruß
Georg
Ich hatte mal so ein ähnliches Problem mit nem CAN Bus Transceiver auf den ISP Ports.
Immer wieder mal liess sich der Controller nicht flashen und schien Tot zu sein.
Der Grund war, das sich die Fuses für die Takteinstellung verstellt hatten.
Nachdem ich einen extern Takt angelegt hatte, konnte ich die Fuses neu setzen und der Controller funktionierte wieder.
Erst als der Can Transceiver mittels Pull Down Widerstand auf der !CE Leitung "stumm" geschaltet wurde trat das Problem nicht mehr auf.
Da beim ATMEGA die nicht benutzten Ports beim proggen in Tri State sind, könnte das Display zeitweise kurze Impulse auf die ISP Pins bringen, die den Programmiervorgang stören bzw. falsch Bits setzen.
Mein Vorschlag wäre die beiden CE Pins des Displays per Pull(up)down auf festes ( inaktives ) Potential zu legen.
Also bei aktiv high ein Pulldown bzw. umgekehrt.
dj_cyborg
28.09.2014, 09:21
Hallo,
hat zwar nichts mit dem Flashen zu tun aber sind die internen Pullups für die Taster eingeschalten? Hatte erst gedacht die Taster wären Öffner, liegt aber wohl an dem Kreuz was da Eagle immer rein macht. Evtl. gabs da mal einen Kurzschluss der dem Chip nicht gut bekam?
Den Gesamtstrom mal gemessen? Evtl. gibts doch irgenwo einen Kurzschluss auf der Platine?
Ansonsten stimme ich Klebewax zu.
mfG
Mario
Danke für alle weiteren Hinweise!
Das Fehlerbild fehlender Cs passt weder zu "geht garnicht" noch zu "stirb langsam" und auch nicht zu "geht kaputt" [...] Damit will ich nicht sagen, daß man Abblocks-Cs vernachlässigen soll, aber sie erklären nicht jedes Problem.
So in etwa meinte ich das auch. Ich geben allen völlig recht, dass ich zu nachlässig mit den Ablock-Cs war. Trotzdem ist der Aufbau weit davon entfernt, keine Abblock-Cs zu haben. Da alles in SMD aufgebaut ist, sind die 100 nF für den µC auch wesentlich näher am Die als sie es jemals bei einem THT/DIP Aufbau sein würden. Aber nochmal: auch das werde ich in Rev. 2 der Platine verbessern!
Für mich erscheint die gemeinsame Nutzung von Pins durch ISP und LCD verdächtig, insbesondere weil sich der Defekt des µCs beim Programmieren zeigt. Wie sehen denn die ISP-Signale aus, wenn sich der Chip nicht programmieren läßt? Geht er doch noch, wenn man das LCD abtrennt? In dieser Richtung würde ich weiter forschen.
Ja, so bin ich ja auch rangegangen. Ich hatte es oben schon mal geschrieben: beim Versuch zu flashen tut sich nichts auf MISO, die anderen Signale sehen sinnvoll aus (habe aber nicht im Detail in die Daten geguckt). Habe das LCD auf den betroffenen Signalen zwischenzeitlich auch wieder vom µC getrennt, das hat keinen Erfolg gebracht.
Im folgenden Bild ist der Verlauf der ISP Signale beim Versuch mit AVRDUDE/USBASP zu flashen zu sehen. Ich habe blöderweise die Horizontalskala im Bild abgeschnitten, der low-Puls auf MOSI ist 20 ms lang, das nur zur zeitlichen Orientierung.
29132
EDIT: sch*** Kompression, sorry für die schlechte Qualität. Reihenfolge der Signale: MISO, CLK, MOSI, RST
Der Grund war, das sich die Fuses für die Takteinstellung verstellt hatten.
Nachdem ich einen extern Takt angelegt hatte, konnte ich die Fuses neu setzen und der Controller funktionierte wieder.
Daran hatte ich auch gedacht, habe gestern mal einen externen Taktgeber an PB6 (XTAL1) angeschlossen, leider ohne Erfolg. Andere Möglichkeiten fielen/fallen mir nicht ein, zumindest muss ich ja "Kontakt" zu dem µC bekommen um die Fusebits wieder glattzubügeln - falls das überhaupt das Problem ist.
Mein Vorschlag wäre die beiden CE Pins des Displays per Pull(up)down auf festes ( inaktives ) Potential zu legen.
Also bei aktiv high ein Pulldown bzw. umgekehrt.
Weiß jemand sicher ob die CS Signale beim KS108 active high oder active low sind? Ich habe ein Datenblatt in dem dazu nichts steht, und ein chinesisches dass ich so interpretiere dass sie active high sind. In letzterem Falle würde ich dann natürlich Pull-Downs einsetzen.
hat zwar nichts mit dem Flashen zu tun aber sind die internen Pullups für die Taster eingeschalten?
Die Taster sind ganz normale Schließer. Die sind auf der Platine noch garnicht bestückt, können also bisher keinen Einfluss gehabt haben.
Den Gesamtstrom mal gemessen? Evtl. gibts doch irgenwo einen Kurzschluss auf der Platine?
Hatte ich oben schon geschrieben, die Stromaufnahme liegt bei 80 mA wegen dem LCD Backlight. Die Schaltung funktioniert ja zunächst, insofern kann es keinen "groben" Fehler im Layout geben.
Gruß
Malte
Peter(TOO)
28.09.2014, 11:46
Hallo Malte,
Die Versorgungsspannung sieht okay aus, ich wüsste auch erstmal nicht, wo es da haken könnte. Die Erzeugung der 5V ist 08/15 folgendermaßen realisiert:
29126
Hier ist schon der erste Fehler.
Du solltest noch , möglichst direkt am 7805 noch 100-220nF Keramik (Jeweils parallel zu C4 und C9) schalten.
Ohne diese neigen die 7805 dazu, bei Lastwechseln Transienten zu erzeugen und diese mögen die Halbleiter gar nicht.
MfG Peter(TOO)
- - - Aktualisiert - - -
Du solltest dies hier mal durchlesen:
http://de.wikipedia.org/wiki/Flash-Speicher#Funktionsprinzip
Auf dem Chip befindet sich noch eine Ladungspumpe, welche zum Programmieren eine höhere Spannung erzeugt. Dieser Teil ist nur während des Programmier-Modus aktiv.
Das praktische Problem beim programmieren ist, dass man, um schnelle Programmierzyklen zu haben, relativ nahe an die Durchschlagsspannung der Isolation der Floating Gates gehen muss. Da ist dann kein Platz mehr für Transienten.
Grundsätzlich hat man immer das Problem, dass Ionen aus der Umgebung in die Isolationsschicht wandern. Dies ist auch der Grund für die nur endliche Anzahl von Programmierzyklen, mit den Zyklen wird die Isolationsschicht zerstört.
In den Anfängen (EPROM und EEPROM) lag man so um die 100 Zyklen.
Die erste Generation FLASH-Speicher lag im Bereich von 1'000 bis 10'000 Zyklen, heute liegt man bei 100'000 bis 1'000'000 Zyklen.
MfG Peter(TOO)
Hallo!
Du solltest noch , möglichst direkt am 7805 noch 100-220nF Keramik (Jeweils parallel zu C4 und C9) schalten.
Ja, vielen Dank, das Thema hatten wir ja oben schon mal. Es sind in meinem Falle keine Elkos sondern Tantals an dem 7805 verbaut, das sollte das Problem zwar etwas mildern, aber ich werde die KerKos auf jeden Fall ergänzen.
Gruß
Malte
RoboHolIC
28.09.2014, 21:59
Weiß jemand sicher ob die CS Signale beim KS108 active high oder active low sind?
Der KS0108 / KS0108B besitzen zwei L-aktive und einen H-aktiven Chipselect. Meist ist nur (jeweils) einer davon nach aussen an die Kontaktleiste geführt. Die ChipSelects sind aber nicht der einzige Ansatzpunkt. Die Polarität des R/W ist am Chip eindeutig und wird kaum im LCD-Modul invertiert werden. Hier fürs Erste ein PullDown, dann gibt es keinen Krieg der Ausgangspins mehr. Gleiches gilt alternativ für den Enable-Eingang. Die Polarität der CS lässt sich dann experimentell rausfinden: alle gleichartig setzen oder löschen - entweder fühlen sich beide GLCD-Controller angesprochen oder keiner; das macht keinen Schaden.
Hatte einmal genau das gleiche Fehlerbild, da war der 7805 defekt. Lieferte lt. Multimeter konstante 5V, am Oszi waren aber Peaks bis 10V sichtbar, die innerhalb kurzer Zeit die Atmegas zerstörten. Typischerweise ging das Flashen gut, da hier auch die Stromversorgung vom Flash Adapter einiges ausbügelte. Aber danach blieben nur Minuten bis zum Defekt.
LG!
Hallo!
Hatte einmal genau das gleiche Fehlerbild, da war der 7805 defekt. Lieferte lt. Multimeter konstante 5V, am Oszi waren aber Peaks bis 10V sichtbar, die innerhalb kurzer Zeit die Atmegas zerstörten.
Ganz ausschließen kann ich auch das nicht, allerdings habe ich mir dir Versorgungsspannung relativ genau angesehen. Da ich jetzt eh das PCB überarbeite spendiere ich auch einen neuen 7805.
Die Polarität des R/W ist am Chip eindeutig und wird kaum im LCD-Modul invertiert werden. Hier fürs Erste ein PullDown, dann gibt es keinen Krieg der Ausgangspins mehr. Gleiches gilt alternativ für den Enable-Eingang. Die Polarität der CS lässt sich dann experimentell rausfinden: alle gleichartig setzen oder löschen - entweder fühlen sich beide GLCD-Controller angesprochen oder keiner; das macht keinen Schaden.
Nur noch mal zum Verständnis: Es sollte doch schon genügen R/W auf read, also low zu halten. Damit sollte auf den Datalines nichts mehr passieren. Zusätzlich gibt es ja auch noch einen avtive-low Reset Signal, das ich ebenfalls runterziehen könnte. Für meine Begriffe sind dann weitere Maßnahmen (insb. an enable und den chip selects) an dieser Stelle überflüssig, oder übersehe ich etwas?
Danke!
Gruß
Malte
- - - Aktualisiert - - -
Okay, eigentlich albern zwei Widerstände zu sparen ... also ziehe ich CS1 und CS2 auch noch runter. Das folgende Bildchen gehört lt. Verkäufer zu dem von mir verwendeten LCD, ich lese das so, dass die CSs active high sind.
29140
RoboHolIC
29.09.2014, 21:41
Es sollte doch schon genügen R/W auf read, also low zu halten. Damit sollte auf den Datalines nichts mehr passieren. Zusätzlich gibt es ja auch noch einen avtive-low Reset Signal, das ich ebenfalls runterziehen könnte. Für meine Begriffe sind dann weitere Maßnahmen (insb. an enable und den chip selects) an dieser Stelle überflüssig, oder übersehe ich etwas?
Nein, du übersiehst meines Erachtens nichts. Ich schrieb ja auch, dass der Enable alternativ zum R/W in gleicher Weise den Bus ins TriState schalten kann. Der Reset könnte die selbe Wirkung haben. Darauf verlassen würde ich mich nicht, denn der Reset ist eine interne Angelegenheit des Controllers und hat nicht unmittelbar mit dessen Interface zu tun. Ich meine aber, dass er eben doch im Reset "die Beine hoch zieht"; insofern eine weitere Möglichkeit zur Passivschaltung.
Das folgende Bildchen gehört lt. Verkäufer zu dem von mir verwendeten LCD, ich lese das so, dass die CSs active high sind.
Das sehe ich auch so.
Peter(TOO)
30.09.2014, 02:28
Hallo,
Nein, du übersiehst meines Erachtens nichts. Ich schrieb ja auch, dass der Enable alternativ zum R/W in gleicher Weise den Bus ins TriState schalten kann. Der Reset könnte die selbe Wirkung haben. Darauf verlassen würde ich mich nicht, denn der Reset ist eine interne Angelegenheit des Controllers und hat nicht unmittelbar mit dessen Interface zu tun. Ich meine aber, dass er eben doch im Reset "die Beine hoch zieht"; insofern eine weitere Möglichkeit zur Passivschaltung.
R/W ist eigentlich der falsch Kandidat!
E und die CS wären die Kandidaten.
Der Chip kann nur angesprochen werden wenn E und CS aktiv sind.
Wenn E Low ist sind die Datenleitungen immer hochohmig, egal welchen Pegel R/W hat.
MfG Peter(TOO)
Hallo!
R/W ist eigentlich der falsche Kandidat!
Abgesehen davon, dass mir das nicht ganz einleuchtet ...
Der Chip kann nur angesprochen werden wenn E und CS aktiv sind.
Wenn das "und" ein logisches Und ist, würde es genügen, die CSs low zu halten, richtig? Das habe ich jetzt eh schon so vorgesehen.
Ich frage mich allerdings schon, wie der/die LCD Controller auf die Idee kommen könnten, Einfluss auf die Datenleitungen zu nehmen, wenn sie über R/W in den Lesezustand versetzt werden.
Ich habe ja oben einen Teil der rudimentären Dokumenation zum LCD gepostet, ich entnehme dem, dass Enable positive Logik hat. Sieht jemand das anders? Den Pull-Down werde ich ansonsten nämlich auch noch gerne spendieren - sei er nun "logisch" notwendig oder nicht.
Vielen Dank!
Malte
Peter(TOO)
30.09.2014, 10:43
Hallo Malte,
Wenn das "und" ein logisches Und ist, würde es genügen, die CSs low zu halten, richtig? Das habe ich jetzt eh schon so vorgesehen.
Ich frage mich allerdings schon, wie der/die LCD Controller auf die Idee kommen könnten, Einfluss auf die Datenleitungen zu nehmen, wenn sie über R/W in den Lesezustand versetzt werden.
Ich habe ja oben einen Teil der rudimentären Dokumenation zum LCD gepostet, ich entnehme dem, dass Enable positive Logik hat. Sieht jemand das anders? Den Pull-Down werde ich ansonsten nämlich auch noch gerne spendieren - sei er nun "logisch" notwendig oder nicht.
Es ist ein logisches UND.
Dein Modul hat zwei CS, es genügt wenn einer disabled ist, dann macht das Modul keinen Wank mehr.
MfG Peter(TOO)
Ich frage mich allerdings schon, wie der/die LCD Controller auf die Idee kommen könnten, Einfluss auf die Datenleitungen zu nehmen, wenn sie über R/W in den Lesezustand versetzt werden.
Wenn dem nicht so wäre würde kein RAM auszulesen sein. Nur schreiben möglich.
RoboHolIC
30.09.2014, 11:30
Dein Modul hat zwei CS, es genügt wenn einer disabled ist, dann macht das Modul keinen Wank mehr.
Vorsicht !!!
Ich habe bisher nur KS0108-GLCDs gesehen, bei denen pro 64 Spalten ein Controller verbaut war. Mehr kann dieser Typ nicht.
128x64-Auflösung bedeutet zwei Spaltencontroller: Einer für die linke Hälfte, einer für die rechte Hälfte der Anzeigefläche - und ein gemeinsamer Treiber für die 64 Zeilen.
Damit ist zwingend jeweils ein CS pro Controller anzunehmen.
Das Wahrscheinlichste ist, dass das Blockdiagramm bezüglich der CS's halb falsch und halb richtig gezeichnet ist. Das hatte ich auch schon bei einem anderen GLCD, nämlich dem 192x64-er von P.....
Langer Rede kurzer Sinn: Es müssen BEIDE CS's deasserted (inaktiver Zustand) werden, damit der Datenbus hochohmig ist.
Hallo!
Es ist ein logisches UND.
Dein Modul hat zwei CS, es genügt wenn einer disabled ist, dann macht das Modul keinen Wank mehr.
Ich bezog mich mit der Frage nach dem "UND" auf die CSs und E, so hatte ich Dich, Peter, auch verstanden. Ich habe hier nochmal ein Bild aus dem Datenblatt eines anderen LCDs mit den gleichen Controllern, das verstehe ich so, wie RoboHolIC es darstellt: zwei Controller pro Panel, dementsprechend auch zwei CSs. Es ist ja vor allem kein Problem, beide auf low zu halten. Ich werde zusätzlich jetzt auch noch den Enable inaktiv halten.
29141
Wenn dem nicht so wäre würde kein RAM auszulesen sein. Nur schreiben möglich.
Klingt eigentlich logisch :-). Ich muss zugeben, dass ich GLCDs bisher ausschließlich mit high-level Befehlen benutzt habe, insofern ist mir tatsächlich nicht ganz klar, was wirklich im Detail auf dem Bus passiert. Aber was mir soweit einleuchtet - und hier auch Konsens zu sein scheint - ist, dass der LCD Datenbus hochohmig ist, wenn ich die CSs und E runterziehe.
Danke sehr!
Malte
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.