ATmega8 AU - TQFP Leerlaufstrom zuckt sich hoch bis zum µC-TOD

[Tom S. (tomsawer)]

Ich löse gerne Rätsel und Knobel alleine bis ichs gefunden habe aber in 
diesem Fall geraten Lehrgeld und Zeit langsam aus den Ufern.

Dies ist eine 8x4 LED Matrix-Treiber Patine im hübschen Trapezdesign.

Die MosFETs sind ein bisschen kräftiger ausgeführt. Ist mein erstes mal 
TQFP , Tantal-Elko sowie PCB-Service, weshalb der weiße Bestückungsdruck 
so verpeilt ist (ich wollte gar keinen, habem die einfach gemacht).
Der Programmer ist 6Pin ISP und wird mit Federkontakten dran gehängt 
(wegen dem flachen Design!)

Aus Ehrgeiz etwas zu finden sind nun bereits 6 Boards mit dem Fehler 
infiziert.
Die Fehlersymptome sind á la Gauß recht gut verteilt. 2 Platinen gehen 
aber sind an der Grenze zu Fehlverhalten, 3 haben böse Fehler und einer 
ist Tod.
Die Fehler sind auch je nach Tageszeit und Mondstand anders. Ich 
beobachte und suche seit einer Woche immer wieder.

--- Erstes Board

Das erste Board habe ich in Microschritten in Betrieb genommen:
- Spannungregler (Ist ein LM 1117 5.0V) und Tantals löten -> 12V dran -> 
5V raus
- Controller löten -> ISP getestet
- rest löten -> getestet
- Leeres Program getestet
- Heartbeat-LED getestet
- Und so weiter... bis die Matrix komplett lief.
->  (später fand ich heraus das auch dieses Board Reset ist 
überempfindlich und lößt bereits durch die Osszi-Spitze aus)

--- Zweites Board

Schön dachte ich, keine Fehler gemacht. Also die nächste Platine in 
einem Rutsch bestückt, Auf Kurzschlüsse geprüft und angeschlossen.
Strom stimmt, ISP geht ABER sobald ich das Programm auf dem Controller 
hatte kam der Dämon.

Der Controller lößte andauern Reset aus. Der Reset Pin war auch 
unstabil. Schnell den Strom ab und erstmal ROM-erase.
Dennoch der Rest blieb instabil. Ich fummelte noch eine Weile und fiel 
mir auf das der Strom 900mA gestiegen war.
ISP ging nicht mehr und Tod für immer.

Was war das? keine Kurzschlüsse, Output-PINs die zu kurzschlüssen 
führen,,, einfach nichts!

--- drittes Board

Also nochmal in Zeitlupe bestückt wie beim ersten Board. Ohne Program, 
alles gut. Stromaufnahme liegt bei ca. 4mA
Aber sobal das obligatorische...

int main ( void ) {
  for(;;) {
  }
  return 1;
}

...im RAM liegt gehts wieder Los:
der Zeiger auf dem Drehspulmegerät fängt an zu zucken, irgendwann kommt 
dann ein größeres Zucken und er arbeitet sich langsam hoch. erst auf 
10mA, dann 20 und 30 und nach 2 Minnuten ist er dann bei 60mA.

Jeder der folgenden Controller hatte dabei sein eigenes Tempo und 
Rhythmus Noch kann man alle bis auf die 2 Leichen via ISP erreichen und 
Programme flashen  und die Programme werden sogar manchmal abgespielt.

Allerdings ist Reset nicht mehr auf VCC sondern irgendwo zwischen 2 und 
3V. Manche Controller Reseten sobald die PORTS als Ausgänge geschaltet 
werden.

--- Was ich noch Erfolglos probiert habe
- Spannungsregler überbrücken und 5V aus Labornetzteil direkt
- kleineren Reset-Pullup (ab 3k schaffts der AVRISP-MK2 nicht mehr 
runter zu ziehen)
- denselben Controller auf Breadboard zum laufen gebracht aber nur mit 
ISP und 5V -> Erfolgreich

--- Vermutungen:

- Ein fieser Platinendesign-Fehler (Zu wenig Blockkondensatoren, 
schlechte Leiterbahnführung
- Der Inhalt der Software (wirds kaum sein, da nur ein Infinite loop 
rasselt und keinerlei Register gesetzt werden)
- Die Fusebits (sind bei allen Controllern auf Werkseinstellung: 1Mhz, 
Kein Brown Out)
- Die 12V Versorgung der P-Channel MOSFETs schlägt auf exotische Weise 
durch.
- Die Gatekapazität der N-Channel MOSFETs

[Tom S. (tomsawer)]

Hier noch das Assembler Prog vom Compiler:

HELL_Matrix.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000003e  00000000  00000000  00000054  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .stab         000006cc  00000000  00000000  00000094  2**2
                  CONTENTS, READONLY, DEBUGGING
  2 .stabstr      00000054  00000000  00000000  00000760  2**0
                  CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00000000 <__vectors>:
   0:  12 c0         rjmp  .+36       ; 0x26 <__ctors_end>
   2:  19 c0         rjmp  .+50       ; 0x36 <__bad_interrupt>
   4:  18 c0         rjmp  .+48       ; 0x36 <__bad_interrupt>
   6:  17 c0         rjmp  .+46       ; 0x36 <__bad_interrupt>
   8:  16 c0         rjmp  .+44       ; 0x36 <__bad_interrupt>
   a:  15 c0         rjmp  .+42       ; 0x36 <__bad_interrupt>
   c:  14 c0         rjmp  .+40       ; 0x36 <__bad_interrupt>
   e:  13 c0         rjmp  .+38       ; 0x36 <__bad_interrupt>
  10:  12 c0         rjmp  .+36       ; 0x36 <__bad_interrupt>
  12:  11 c0         rjmp  .+34       ; 0x36 <__bad_interrupt>
  14:  10 c0         rjmp  .+32       ; 0x36 <__bad_interrupt>
  16:  0f c0         rjmp  .+30       ; 0x36 <__bad_interrupt>
  18:  0e c0         rjmp  .+28       ; 0x36 <__bad_interrupt>
  1a:  0d c0         rjmp  .+26       ; 0x36 <__bad_interrupt>
  1c:  0c c0         rjmp  .+24       ; 0x36 <__bad_interrupt>
  1e:  0b c0         rjmp  .+22       ; 0x36 <__bad_interrupt>
  20:  0a c0         rjmp  .+20       ; 0x36 <__bad_interrupt>
  22:  09 c0         rjmp  .+18       ; 0x36 <__bad_interrupt>
  24:  08 c0         rjmp  .+16       ; 0x36 <__bad_interrupt>

00000026 <__ctors_end>:
  26:  11 24         eor  r1, r1
  28:  1f be         out  0x3f, r1  ; 63
  2a:  cf e5         ldi  r28, 0x5F  ; 95
  2c:  d4 e0         ldi  r29, 0x04  ; 4
  2e:  de bf         out  0x3e, r29  ; 62
  30:  cd bf         out  0x3d, r28  ; 61
  32:  02 d0         rcall  .+4        ; 0x38 <main>
  34:  02 c0         rjmp  .+4        ; 0x3a <_exit>

00000036 <__bad_interrupt>:
  36:  e4 cf         rjmp  .-56       ; 0x0 <__vectors>

00000038 <main>:
  38:  ff cf         rjmp  .-2        ; 0x38 <main>

0000003a <_exit>:
  3a:  f8 94         cli

0000003c <__stop_program>:
  3c:  ff cf         rjmp  .-2        ; 0x3c <__stop_program>

Die ISR kommt anscheinend noch aus einer lib.

[Charly B. (charly)]

Tom Sawer schrieb:

> --- Was ich noch Erfolglos probiert habe
> - Spannungsregler überbrücken und 5V aus Labornetzteil direkt

> --- Vermutungen:
> - Die 12V Versorgung der P-Channel MOSFETs schlägt auf exotische Weise
> durch.

Kann doch dann nitt sein, oder ?

ich hab immer noch ein C nach GND am reset

kannste die Eagle files einstellen oder mailen?

vlG
Charly

[David P. (chavotronic)]

Meine Glaskugel geht grad nicht, würde aber auf ein Problem in deiner 
Spannungsversorgung tippen. Arbeitet der Regler stabil? Bitte schau dir 
die 5V mit dem Oszi an.
von RST zu GND mal einen 100nF Kondensator dranmachen, das kann nicht 
schaden.

[g457 (Gast)]

> 00000038 <main>:
>   38:  ff cf         rjmp  .-2        ; 0x38 <main>

mach doch mal was vernünftiges:
1. Zeig den echten Quellcode, keine Ausgaben vom Compiler. Der Fehler 
liegt höchstwahrscheinlich irgendwo bei Dir.
2. Setze die Ausgänge auf definierte Zustände. High-Z ist eine ganz 
schlechte Idee wenn man keine Pull-Ups/-Downs verbaut.

HTH

[David P. (chavotronic)]

Die Stelle da in der Mitte sieht kritisch aus.

[Toni (Gast)]

Aref direkt an VCC darf nicht sein, lege bitte Aref mit 100nF an GND.
Aref an VCC gibt spätestens dann Problem wenn aktiviert.
VCC als Aref kann beim ADC direkt angegeben werden, schaltet dann
intern um.

[Helmut L. (helmi1)]

IC1 = welcher Type?
AREF gehoert nicht an VCC

[Marco F. (m8_killer)]

Hallo,
Eventuell mehr Vias bei der Groundfläche, hatte mal ein ähnliches 
problem und bei mir hat die abschirmung eine schleife gebildet. Und 
schleifen sind empfänglich für induktionen. Vermutlich erst recht mit 
ARef an VCC.

Gruß Marco

[Karl H. (kbuchegg)]

Hab ich Tomaten auf den Augen?
Mir fehlen auch die Blockkondensatoren am Mega.

[Karl H. (kbuchegg)]

> - Ein fieser Platinendesign-Fehler (Zu wenig Blockkondensatoren,
>   schlechte Leiterbahnführung

Ich weiß ja nicht wie gut deine Augen sind.
Aber mir wäre da die Clearance zwischen den Bahnen (bzw. zwischen der 
GND_Plane und den Bahnen viel zu gering).

[Ben _. (burning_silicon)]

Die eher störend großen Masseflächen sind mir auch schon aufgefallen...

Wie wird denn das Board versorgt, was nimmt am Ende diesen immensen 
Strom auf? Nicht, daß da irgendwas in der Stromversorgung stirbt. Ein 
TQFP µC, der 5V/900mA umsetzt fängt sofort an zu dampfen.

[Simon K. (simon)]

Die ca. 900mA könnten der Anschlag der Strombegrenzung der LM1117 sein. 
Wird der sehr warm?

[Paul Baumann (Gast)]

Kannst Du Vss abmachen, damit die ganzen Treibertransistoren nicht mehr
am Geschehen teilnehmen?

So könnte man feststellen, ob der Kontroller selbst den hohen Strom
aufnimmt, oder jemand Anderer.

Mit einem DIL-Schaltkreis als Kontroller in einer Fassung hätte man 
jetzt
bessere Karten...
(Ich liebe SMD-Gelumpe)
;-)

MfG Paul

[Simon K. (simon)]

Paul Baumann schrieb:
> Mit einem DIL-Schaltkreis als Kontroller in einer Fassung hätte man
> jetzt
> bessere Karten...

In DIL hätte er es wohl kaum auf der Fläche untergebracht.

[Toni (Gast)]

Sehe ich das nur auf den Bildern falsch, um die
Widerstände ist eine ganz dünne Linie -in der gleichen Farbe wie
das Kupfer- ist die womöglich auch im realen Kupfer vorhanden?

Meiner Erfahrung nach sollten diese Linien, wenn tatsächlich im
Leiterbahnbild, spätestens mit dem Ätzen verschwinden.
Aber nix genaues weiß man nicht. Prüfe das mal auf Kurzschlüsse.

[Tom S. (tomsawer)]

Hallo!

Danke für die Zahlreichen Antwoorten!

Aref hab ich jetzt in der Luft hängen. Danke für den Hinweis!
Die beiden GRN VCC Eingänge liegen ja direkt nebeneinander darum habe 
ich hier nur einen Abblockkondensator.
Zu wenig? Braucht den AVCC auch einen? Ich nutze den ADC ja nicht...

Der Strom geht in den Controller. Nur diesen mit 5V zu versorgen und die 
FETs links liegen zu lassen ahtte ich schon.

Kurzschlüsse habe ich keine, wie gesagt 100fach geprüft, optisch, 
gepiepst... Ich hab mir Lötstoplack für die Platine geleistet. Die 
Stelle in der Mitte ist nicht kurzschlussgefährdet.
---

Die Controller hab ich alle in eine Box getan und heute mittag mal einen 
auf nen Addapter und auf ein Breadboard gepackt und siehe da er ging 
noch!

Alle anderen sind auch am Leben!
Ich habe mit allen das Blinkeprogrämmchen laufen lassen:

#include <avr/io.h>
#include <util/delay.h>

int main(void) {

  DDRB |= (1 << PB4);

  _delay_ms(1000);

  for (;;) {
    int i;
    for (i = 10; i < 100; i++) {
      PORTB ^= (1 << PB4);

      for (int t = 0; t <= i; t++) {
        _delay_ms(1);
      }
    }
    for (;i > 0; i--) {
      PORTB ^= (1 << PB4);

      for (int t = 0; t <= i; t++) {
        _delay_ms(1);
      }
    }
  }
    return 1;
}

Stromaufnahme, Reset alles OK!
nun hab ich die Boards alle nochmal durch gepiept und die FETs getestet. 
Auch alles Tip Top

Also hab ich einen Controller wieder auf das Board gemacht und es ging 
Strom war i.O.

------------------
ABER! Hier kommts und schärfer kann ich den Fehler bisher nicht 
eingrenzen. Wenn ich nun das selbe Testprogramm, das ja noch auf dem µC 
läuft mit der ISP des Boards flashe, ist der Fehler wieder da.
Auch ein chiperase bei AVRdude hilft nichts
------------------

Obwohl AVR-Dude nicht meckert und auch richtig verifiziert:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9307
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "Matrix.hex"
avrdude: input file Matrix.hex auto detected as Intel Hex
avrdude: writing flash (174 bytes):

Writing | ################################################## | 100% 0.08s

avrdude: 174 bytes of flash written
avrdude: verifying flash memory against Matrix.hex:
avrdude: load data flash data from input file Matrix.hex:
avrdude: input file Matrix.hex auto detected as Intel Hex
avrdude: input file Matrix.hex contains 174 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.04s

avrdude: verifying ...
avrdude: 174 bytes of flash verified
avrdude: reading input file "0xe4"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xe4:
avrdude: load data lfuse data from input file 0xe4:
avrdude: input file 0xe4 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xd9"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xd9:
avrdude: load data hfuse data from input file 0xd9:
avrdude: input file 0xd9 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified

avrdude done.  Thank you.

avrdude finished

Alsio der Programmer! Ich muss mal was essen.

Die Leitungen ISP Leitungen tummeln sich hier und da zwischen den 
N_Channel MOSFETS, dort ist ja nichts los, solange

[Tom S. (tomsawer)]

g457 schrieb:
>> 00000038 <main>:
>>   38:  ff cf         rjmp  .-2        ; 0x38 <main>
>
> mach doch mal was vernünftiges:
> 1. Zeig den echten Quellcode, keine Ausgaben vom Compiler. Der Fehler
> liegt höchstwahrscheinlich irgendwo bei Dir.
> 2. Setze die Ausgänge auf definierte Zustände. High-Z ist eine ganz
> schlechte Idee wenn man keine Pull-Ups/-Downs verbaut.
>
> HTH

Die FEts haben doch alle Ihre eigenen Pullups Pulldowns. Ich wollte 
erstmal sicher gehen und hab das sein gelassen!

Aber ich werds gliech ausporbieren!

[Tom S. (tomsawer)]

David P. schrieb:
> Die Stelle da in der Mitte sieht kritisch aus.

ISt alles Ordnung dort. Der Lötstoplack macht seinen Dienst!

[Tom S. (tomsawer)]

Simon K. schrieb:
> Paul Baumann schrieb:
>> Mit einem DIL-Schaltkreis als Kontroller in einer Fassung hätte man
>> jetzt
>> bessere Karten...
>
> In DIL hätte er es wohl kaum auf der Fläche untergebracht.

Korrekt korrekt. Das Format war der Entscheidungspunkt für SMD. Für ne 
Kühlschranksteuerung würde ich mich auch durch gesockelte ICs entlasten 
;-)

[Tom S. (tomsawer)]

Hier das PCB im letzten Stadium! 3 Platienn sehen jetzt so aus. Ich 
glaube es wirkt. Der Fehler ist aber bei einer noch da!

AREF hängt in der Luft!

Vielleicht doch futsch der AVR?
An der Haupt-Stromversorgung

GND    -   Pin 3
 |direkt Verb.|
GND    -   Pin 5
 |    100nF   |
VCC    -   Pin 4
 |direkt Verb.|
VCC    -   Pin 6

Hier reicht doch einer oder?!?!

[Tom S. (tomsawer)]

ok ich hab jetzt 5 Chips auf dem neuen Level. Alle lassen sich flashen 
mit dem Testporgramm und sie arbeite auch.

Nur einer ist anscheinend entgültig hin.

Also ein ohne zweiten 100n geflashter Controller in meinem Design macht 
Mist. Obwohl AVRdude den Code positiv verifiziert hatte. 
Abblockkondesnatoren.. Das Sie so einen fiesen Fehler machen können!

Ich dachte, dann geht einfach nix oder Software macht Mist. Aber das es 
zu so ner Katastrophe kommt finde ich sehr intensiv.

... Anstrengend aber äusserst Lehrreich!

Ich beobachte das mal und Porbiere mit dem Final-Programm rum. WEnns 
alles klappt oder nicht klappt, gibts die News!
Jetzt aber wirklich erst mla was futtern :-/

Danke, Danke, Danke! Ich werde in zukunf nach 3 Tagen Kopf rauch zu euch 
kommen und nicht nach ner Woche :-D

Wozu so viel Leistung: wird ne Matrix mit 1A LEDs!

[Kay (Gast)]

Tom Sawer schrieb:
> Abblockkondesnatoren.. Das Sie so einen fiesen Fehler machen können!

Ach quatsch. Die sind unnötig. Der Hersteller schreibt das nur zum Spaß 
in sein Datenblatt :-)

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Tom Sawer schrieb:
> Abblockkondesnatoren.. Das Sie so einen fiesen Fehler machen können!

Das kann man auch technisch/'wissenschaftlich' erklären: Die MCs werden 
ja in CMOS/NMOS Technologie gefertigt. Prinzipbedingt entsteht beim 
Schalten hier ein von der Schaltgeschwindigkeit abhängender Ladestrom, 
je schneller ein MC getaktet wird, umso höher sind diese Ladeströme (in 
der Summe). Zum Auffangen dieser Umladeströme sind die 
Abblockkondensatoren. Und da grosse Kondensatoren nicht auf dem Substrat 
des Chips integriert werden können, empfehlen alle Hersteller, diese so 
nahe wie möglich am MC zu positionieren. Meistens ist das Layout der 
Pins schon darauf ausgelegt. Bei dem XMegas z.B. sind die Vcc und GND 
Pins in Pärchen rund um den Chip, an jedes einen Abblock-C und der MC 
läuft sauber.
Ich nehme normalerweise eine Kombination aus Elko und Keramik-C 
(22-100uF/100n), um Stromreserve für die o.a. Umladeströme zu haben und 
die Peaks abzufangen. Wenn die Cs nicht direkt am Chip sind, solltest du 
wenigstens dicke Bahnen für GND und Vcc benutzen, um die etwas 
abgesetzten Cs wirksam zu machen.

[Simon K. (simon)]

Weiß nich, das wäre zu einfach gewesen. Ich glaube das Problem liegt 
woanders.

Wie programmierst du das Ding? Was für ein Programmieradapter? Welche 
Spannungen? Welcher Anschluss?

[M. B. (Firma: TH Nürnberg) (ohmen)]

Auf dem Bild scheint bei einigen Widerständen die zweite Seite nicht 
gelötet zu sein...

[Helmut L. (helmi1)]

Das fehlen von Abblockkondensatoren erklaert aber nicht die hohe 
Stromaufnahme des Chips.

Eine Moeglichkeit das der Chip eine zu hohe Stromaufnahme hat ist der 
Latchup. Bei C-MOS IC gibt es Prinzip bedingt parasitaere Thyristoren 
auf dem Chip. Die koennen zuenden und dir Versorgungsspannung 
kurzschliessen wenn an einem Eingang die Spannung ueber die Versorgung 
gezogen wird. Das kann zum Beispiel passieren wenn beim Programmieren 
die Spannung an den Pins zuerst da / grosser als die Versorgungspins 
ist.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Helmut Lenzen schrieb:
> Das fehlen von Abblockkondensatoren erklaert aber nicht die hohe
> Stromaufnahme des Chips.

Mögl. doch - ein Latchup in einer Push-Pull Ausgangsstufe kann genau von 
einer Spannungspitze im falschen Moment kommen.
Und es scheint beim TE jetzt ja auch zu klappen.

[Helmut L. (helmi1)]

@Matthias Sch.

C2 , C7 vom Spannungsregler sind auch nicht gerade weit entfernt vom uC.
Die sollten das eigentlich verhindern. Es sei den die hat er auch nicht 
bestueckt und der Regler hat ein Ueberschwingen verursacht.

[Hubert G. (hubertg)]

Das C2 und C7 nicht weit vom µC entfernt sind, halte ich für ein 
Gerücht.
Schau dir einmal den GND Weg und Leiterbahnbreite von der 
Spannungsbuchse bis zum GND am µC an und dann definierst du "nicht weit 
entfernt".

[Simon K. (simon)]

Hubert G. schrieb:
> Das C2 und C7 nicht weit vom µC entfernt sind, halte ich für ein
> Gerücht.
Aufgrund der Platinengröße kann es schon gar nicht sooo weit weg sein.

Aber es kann nicht sein, dass eine Schaltung wegen einem Einzigen 
Abblockkondensator, der zudem ganz in der Nähe eines Anderen sitzen 
würde, nicht funktioniert.
Das würde ja bedeuten, dass die Schaltung so gerade an der Grenze ihrer 
Stabilität arbeitet.

Ich vermute eher, dass er einen Bastelprogrammer (ohne Pegelwandler) 
benutzt und darüber einen Latchup erzeugt hat.

Matthias Sch. schrieb:
> Und es scheint beim TE jetzt ja auch zu klappen.

Ja, scheinen ist das Stichwort.

[Helmut L. (helmi1)]

Hubert G. schrieb:
> Das C2 und C7 nicht weit vom µC entfernt sind, halte ich für ein
> Gerücht.
> Schau dir einmal den GND Weg und Leiterbahnbreite von der
> Spannungsbuchse bis zum GND am µC an und dann definierst du "nicht weit
> entfernt".

Alles noch keine riesigen Entfernung. Frueher zu Zeiten von DIL + Co 
waren die Entfernungen zwischen IC und Cap noch wesentlich laenger. Auch 
da passierte nichts. Da waren die VCC und GND Pins sogar extrem schlecht 
am IC verteilt. Meistens an PIN 40=VCC und 20=GND. Bei sowas duerfte das 
IC nie funktioniert haben. Auch gab es frueher in den seltesten Faellen 
GND + VCC Plaenes. Alles schoen mit duennen Bahnen versorgt.

[Steffen W. (derwarze)]

Das Problem kann durchaus von der VCC und Vref Verbindung kommen.
Wenn die interne Referenz eingeschaltet ist und der Vref Pin mit einer 
höheren Spannung verbunden ist macht das Probleme.
Das Latchup-Problem kann man sich beim Programmieren auch schnell mit 
einer unsauberen Mssseverbindung einhandeln. Ich hab mir eine 
Erdungsschiene gemacht mit der ich jeweils Compi, Baugruppe und 
Versorgung auf gleiches Potential bringe.

[Hubert G. (hubertg)]

Dann verfolge mal den GND-Weg. Direkt wäre es nicht mal 1cm, über den 
Umweg sind es gerne 6cm oder mehr.
Den Latchup würde ich nicht von der Hand weisen, bei den Mega8 neuerer 
Fertigung am Reset-Pin leicht nachvollziehbar. In der App-Note AVR042 
wurde darauf schon reagiert.

[Simon K. (simon)]

Steffen Warzecha schrieb:
> Das Problem kann durchaus von der VCC und Vref Verbindung kommen.
> Wenn die interne Referenz eingeschaltet ist und der Vref Pin mit einer
> höheren Spannung verbunden ist macht das Probleme.
> Das Latchup-Problem kann man sich beim Programmieren auch schnell mit
> einer unsauberen Mssseverbindung einhandeln. Ich hab mir eine
> Erdungsschiene gemacht mit der ich jeweils Compi, Baugruppe und
> Versorgung auf gleiches Potential bringe.

Der ADC war laut TO nie in Betrieb, von daher eher auszuschließen. Und 
standardmäßig ist die Referenz abgeschaltet.

[Axel S. (a-za-z0-9)]

Tom Sawer schrieb:

> der Zeiger auf dem Drehspulmegerät fängt an zu zucken, irgendwann kommt
> dann ein größeres Zucken und er arbeitet sich langsam hoch. erst auf
> 10mA, dann 20 und 30 und nach 2 Minnuten ist er dann bei 60mA.
>
> Jeder der folgenden Controller hatte dabei sein eigenes Tempo und
> Rhythmus Noch kann man alle bis auf die 2 Leichen via ISP erreichen und
> Programme flashen  und die Programme werden sogar manchmal abgespielt.

Es wurde zwar schon mal erwähnt, aber dann nie wieder: unbenutzte Pins 
müssen auf definiertem Potential liegen. Floatende CMOS Eingänge können 
sonst ganz schnell zu eben diesem Verhalten führen. Abhängig von der 
Sauberkeit der Platine und was auf benachbarten Pins abgeht.

Also entweder

1. Pin als Input definieren, Pullup aktivieren (Port auf 1 setzen).
2. Pin als Input definieren und extern auf z.B. GND legen.
3. Pin als Ausgang definieren, auf beliebigen Wert setzen.

Ich bevorzuge Variante 1. Variante 2 ist ok für Serie (wenn man sicher 
ist, einen unbenutzten Pin auch wirklich nicht zu brauchen). Variante 3 
kann zu häßlichen Leckströmen führen, wenn der Pin auf der Platine 
vielleicht doch nicht isoliert ist.

> Allerdings ist Reset nicht mehr auf VCC sondern irgendwo zwischen 2 und
> 3V. Manche Controller Reseten sobald die PORTS als Ausgänge geschaltet
> werden.

An Reset gehören ca. 10K nach Vcc. Immer. Auch wenn Atmel das nicht ins 
Datenblatt schreibt. Und BOD gehört enabled und die Schaltschwelle 
passend zu Vcc gesetzt.


XL

[spess53 (Gast)]

Hi

>Es wurde zwar schon mal erwähnt, aber dann nie wieder: unbenutzte Pins
>müssen auf definiertem Potential liegen. Floatende CMOS Eingänge können
>sonst ganz schnell zu eben diesem Verhalten führen.

Das wurde hier schon mehrmals bis zum Abwinken diskutiert. z.B.

Beitrag "Unbenutzte AVR-Pins wie beschalten (EMV)?"

Bei AVRs führen offene Eingänge nicht zu den beschriebenen Auswirkungen.

MfG Spess

[Simon K. (simon)]

Axel Schwenke schrieb:
> An Reset gehören ca. 10K nach Vcc. Immer. Auch wenn Atmel das nicht ins
> Datenblatt schreibt. Und BOD gehört enabled und die Schaltschwelle
> passend zu Vcc gesetzt.

Der IC gehört so beschaltet, wie vom Hersteller angegeben wird - IMMER.

Und deswegen gibt es von Atmel auch die AVR042:
http://www.atmel.com/images/doc2521.pdf

Dort steht unter Anderem
----
The reset line has an internal pull-up resistor, but if the environment 
is noisy it can be
insufficient and reset can therefore occur sporadically. Refer to 
datasheet for value of
pull-up resistor on specific devices
----
The recommended
pull-up resistor is 4.7kΩ or larger when using STK500 for programming. 
For
debugWIRE to function properly, the pull-up must not be smaller than 
10kΩ
----

[Jörg W. (dl8dtl) (Moderator)]

Wie kommt eigentlich das /RESET vom ISP-Stecker an den Controller?
Im Schaltplan sehe ich da keine Verbindung.

Die Verbindung von AREF mit Vcc ist unglücklich, aber nicht störend,
solange du den ADC nicht aktivierst.

Wenn du schon alles mit Masseflächen auffüllst und die Platine auch
fertigen lässt, solltest du nicht geizig mit Vias sein, um die etwas
zerklüfteten Masseflächen von Ober- und Unterseite miteinander zu
verbinden.  Gerade oben in der Mitte (zwischen den Anschlusspads)
hätte sich ein weiterer Via gut gemacht.

AVcc ist übrigens keineswegs nur für die Versorgung des ADCs
zuständig, sondern es versorgt auch die Pad-Zellen des Ports, an
dem die ADC-Eingänge hängen (Port C beim ATmega8).  Insofern ist
es ein völlig normaler Versorgungsanschluss, der seinen eigenen
Abblockkondensator benötigt.  Generell gilt als Regel: ein Abblock-
kondensator gehört an jedes Vcc/GND-Pinpaar.  Nicht umsonst führen
die Hersteller diese nämlich stets als Pinpaar heraus.

Warum das Teil in den Latchup geht, lässt sich trotzdem kaum erklären,
außer vielleicht damit, dass du einen Programmer hast, der in die
/RESET-Leitung noch Störungen einspeist: /RESET muss 12-V-fähig sein,
um die Parallelprogrammierung intern aktivieren zu können.  Daher hat
dieser Pin (als einziger) keine Schutzdiode nach Vcc.  Die von Simon
bereits ins Feld geführte Appnote AVR042 (bzw. die Schwester-Appnote
AVR040) empfiehlt daher die Benutzung einer externen Schutzdiode an
diesem Pin.

[Axel S. (a-za-z0-9)]

Simon K. schrieb:
> Axel Schwenke schrieb:

>> An Reset gehören ca. 10K nach Vcc. Immer. Auch wenn Atmel das nicht ins
>> Datenblatt schreibt. Und BOD gehört enabled und die Schaltschwelle
>> passend zu Vcc gesetzt.
>
> Der IC gehört so beschaltet, wie vom Hersteller angegeben wird - IMMER.
> Und deswegen gibt es von Atmel auch die AVR042:
> Dort steht *unter Anderem*
> ----
> The reset line has an internal pull-up resistor, but if the environment
> is noisy it can be insufficient ...

Mir ist vollkommen bewußt was da steht. Danke trotzdem für die 
(versuchte) Belehrung. Mir ist aber genauso bewußt, daß zumindest meine 
ATMega8 alle einen externen Pullup brauchten, um korrekt zu 
funktionieren. Und das obwohl im Datenblatt steht, daß es einen 
internen Pullup gibt.

Es steht dir natürlich vollkommen frei, lieber weiter blind dem 
Datenblatt zu glauben und die Praxis zu ignorieren...


XL

[Jörg W. (dl8dtl) (Moderator)]

Axel Schwenke schrieb:
> Mir ist aber genauso bewußt, daß zumindest meine
> ATMega8 alle einen externen Pullup brauchten, um korrekt zu
> funktionieren.

Hängt davon ab, was da angeschlossen ist.  Wenn man an dem Pin
keine weiteren Leitungen dran hat und in EMV-mäßig ruhiger
Umgebung arbeitet, kommt man durchaus ohne externen Pullup aus.
Allerdings ist der ATmega8 auch designmäßig schon etwas ältlich,
die späteren AVRs sind in dieser Hinsicht besser geworden.

Wenn man mit dem Gedanken spielt, einen neueren AVR über debugWIRE
zu debuggen (PDI dürfte im gleichen Boot sitzen, da dort auch die
/RESET-Leitung als PDI_CLK benutzt wird), dann sollte man zumindest
für den Prototypen, der noch debuggt werden soll, erst einmal die
auf der Platine vorgesehenen Bauteile für /RESET nicht bestücken
(eventuell mit Ausnahme der Diode gegen Vcc, die stört nicht).
Gerade debugWIRE als Eindrahtbus ist ziemlich pingelig, wenn die
RC-Konstanten nicht im vorgesehenen Bereich liegen.

[Hubert G. (hubertg)]

Ich bin mir sicher das die Probleme in der Schaltung durch eine ganz 
elende Masseführung hervorgerufen werden. (Softwarefehler mal hintan 
gestellt).
Man muss sich in das Layout nur mal den Weg von Spannungseingang GND zum 
GND des µC einzeichnen. Dann parallel dazu den Weg von den FETs zu 
GND-Eingang.
Durch Kondensatoren wird dieses Problem nur verschleiert.

[Simon K. (simon)]

Hubert G. schrieb:
> Ich bin mir sicher das die Probleme in der Schaltung durch eine ganz
> elende Masseführung hervorgerufen werden. (Softwarefehler mal hintan
> gestellt).
> Man muss sich in das Layout nur mal den Weg von Spannungseingang GND zum
> GND des µC einzeichnen. Dann parallel dazu den Weg von den FETs zu
> GND-Eingang.
> Durch Kondensatoren wird dieses Problem nur verschleiert.

Wie sollte ein solches Problem das Hochschaukeln des Stromes verursachen 
können, frage ich mich.

Ich bleib dabei, dass ein Billiger Programmer den Chip in den Latchup 
schickt, wenn der Chip nicht versorgt wird oder der Programmer keine 
Pegelwandler hat.

[Jörg W. (dl8dtl) (Moderator)]

Simon K. schrieb:
> Ich bleib dabei, dass ein Billiger Programmer den Chip in den Latchup
> schickt, wenn der Chip nicht versorgt wird oder der Programmer keine
> Pegelwandler hat.

Davon allein sollte der Chip nicht in den Latchup gehen, da der
Strom dann einfach über die Eingangsschutzdioden nach Vcc fließt.
Mit einer Ausnahme eben: /RESET hat intern keine solche Diode, dort
muss man sie in seiner Schaltung vorsehen.

[Hubert G. (hubertg)]

Überlege mal welche Induktivitäten und Kapazitäten und damit 
Schwingkreise du da aufbauen kannst und hier auch aufgebaut sind.
Wenn das mal zu schwingen anfängt, bist du blitzartig weit außerhalb der 
Spezifikationen. Was dann passiert kann dir kaum jemand sagen.

[Jörg W. (dl8dtl) (Moderator)]

Hubert G. schrieb:
> Überlege mal welche Induktivitäten und Kapazitäten und damit
> Schwingkreise du da aufbauen kannst und hier auch aufgebaut sind.

Naja, ich sehe da kaum mehr als 100 nH (10 cm gestreckte Leitung)
und 100 pF zusammenkommen, das wären 50 MHz Resonanzfrequenz.

[Helmut L. (helmi1)]

Simon K. schrieb:
> Ich bleib dabei, dass ein Billiger Programmer den Chip in den Latchup
> schickt, wenn der Chip nicht versorgt wird oder der Programmer keine
> Pegelwandler hat.

Dass ist auch meine Meinung, Simon.

Jörg Wunsch schrieb:
> Davon allein sollte der Chip nicht in den Latchup gehen, da der
> Strom dann einfach über die Eingangsschutzdioden nach Vcc fließt.

Vorsicht, wenn der Strom zu hoch wird kann ein parasitaerer Thyristor 
zuenden der den Latchup macht. Ueber dir Schutzdioden sollten nur wenige 
mA fliessen.

[Jörg W. (dl8dtl) (Moderator)]

Helmut Lenzen schrieb:
> Vorsicht, wenn der Strom zu hoch wird kann ein parasitaerer Thyristor
> zuenden der den Latchup macht. Ueber dir Schutzdioden sollten nur wenige
> mA fliessen.

Wir haben schon (versehentlich) ganze AVRs über die Schutzdioden
betriebsfähig versorgt, ohne dass sie in den Latchup gerannt wären.

[Helmut L. (helmi1)]

Jörg Wunsch schrieb:
> Wir haben schon (versehentlich) ganze AVRs über die Schutzdioden
> betriebsfähig versorgt, ohne dass sie in den Latchup gerannt wären.

Das mag sein Joerg. Den Thyristor zu zuenden soll ja auch nicht so 
einfach sein dafuer sorgt schon der Hersteller. Ich hatte mit sowas 
schon mal einen ADC (ICL7109) in den Latchup getrieben. Versorgung ueber 
ein RC-Filter (47 Ohm,47uF) und dann einen Eingang an die ungefilterte 
Versorgung gelegt (also vor dem 47 Ohm). Und schwupp fing er an zu 
kochen an. Man muss da schon einige 100mA Triggerstrom fuer den 
Thyristor bereit stellen. Kannst ja mal versuchen an VCC einen Elko 
(100uF) zu schalten und dann wenn der uC noch nicht versorgt ist einen 
Eingang auf +5V zu legen. So das im Einschaltmoment richtig Strom 
fliesst.

[Oliver S. (oliverso)]

Jörg Wunsch schrieb:
> Wir haben schon (versehentlich) ganze AVRs über die Schutzdioden
> betriebsfähig versorgt, ohne dass sie in den Latchup gerannt wären.

Irgenwo gabs hier mal eine Schaltung für ein Fahrradtacho (?? oder 
ähnliches), da wurde das ganz absichtlich gemacht. Gegen alle Specs, 
funktionierte aber anscheinend reproduzierbar. Grund war, soweit ich 
mich erinnere, die geringere Stromaufnahme dieser Variante...

Oliver

[Simon K. (simon)]

Oliver S. schrieb:
> Jörg Wunsch schrieb:
>> Wir haben schon (versehentlich) ganze AVRs über die Schutzdioden
>> betriebsfähig versorgt, ohne dass sie in den Latchup gerannt wären.
>
> Irgenwo gabs hier mal eine Schaltung für ein Fahrradtacho (?? oder
> ähnliches), da wurde das ganz absichtlich gemacht. Gegen alle Specs,
> funktionierte aber anscheinend reproduzierbar. Grund war, soweit ich
> mich erinnere, die geringere Stromaufnahme dieser Variante...

Das wird vermutlich der berühmte Zero Crossing Detector für 
Phasenanschnitt und Co sein, über den es auch eine Atmel AVR AppNote 
gibt. Mit allen Vor- und Nachteilen.
Es ist, soweit ich weiß, eher als Proof-Of-Concept gedacht und nicht für 
den "harten" ernsthaften Einsatz.


> Jörg Wunsch schrieb:
>> Davon allein sollte der Chip nicht in den Latchup gehen, da der
>> Strom dann einfach über die Eingangsschutzdioden nach Vcc fließt.
>
> Vorsicht, wenn der Strom zu hoch wird kann ein parasitaerer Thyristor
> zuenden der den Latchup macht. Ueber dir Schutzdioden sollten nur wenige
> mA fliessen.

Genau! Und an der lokalen Spannung hängt ja auch noch eine LED Matrix 
oder sowas in der Art? Die würde dann über die Schutzdioden betrieben 
werden.

[Tom S. (tomsawer)]

Interessante Diskussion!

Programmer: AVRISP MK2 mit selbstbau Addapter. Jaja... kringelt euch 
aber dadurch bleibt die Platine schön Flach! Die Zinnaugen haken in die 
Täler der Federkontakte! Kann nicht verrutschen, eher verbiegen die 
Kontakte! Eigentlich waren zwei Zentrierstifte vorgesehen.u

Ich bin mir nun sicher, das Problem war der fehlende Blockup an AVCC!
Den ADC habe ich nicht benutzt und auch nicht initialisiert. AREF an VCC 
war somit offenbar irrelevant. AVCC dachte ich bräuchte dann ja auch 
keinen 100n-C... Irrtum! IMMER ALLE GND-VCC Pärchen blocken. Das ist 
angekommen ;-)

GND hätte ein paar mehr Vias verdient. Die Platine ist aber recht klein 
und daher der längste Weg für GND 2,5cm. Bestimmt nicht kritisch!

Danke habt mir sehr geholfen!

[Jörg W. (dl8dtl) (Moderator)]

Tom Sawer schrieb:
> Programmer: AVRISP MK2 mit selbstbau Addapter. Jaja... kringelt euch
> aber dadurch bleibt die Platine schön Flach!

Cooles Teil.

Ich hatte das letztens mal so gelöst, dass ich oben und unten
verzinnte Pads für einen JTAG-Stecker angebracht habe.  Auf diese
kann man gut klemmend einen 2-mm-Pfostenstecker seitlich aufstecken.
Hat nicht das ewige Leben (die Verzinnung schabt sich ab, und
irgendwann wird das auch schlackerig), aber für einen wenig zu
benutzenden Programmier- oder Debugstecker würde ich das wieder tun.

Schön, dass der Abblockkondensator dein Problem beseitigt hat.  Hätte
ich aber auch nicht gedacht, dass das schon solche Auswirkungen hat,
aber man baut die Teile halt sowieso gewohnheitsmäßig mit drauf. ;-)

[Sascha W. (arno_nyhm)]

Wobei, wenn man sich das Layout mal etwas genauer anschaut, ist die 
Vcc/GND-führung wirklich recht suboptimal - dazu dann die fehlenden 
Abblock-Kondensatoren... Mich wunder nur wie sich so ein Problem 
bemerkbar macht, mit solch erratischen Problemen kann man natürlich 
lange suchen, da es ja kein logischer Rückschluss auf die Fehlerquelle 
möglich ist.
Schön, dass Du es gelöst hast - Ist halt noch eine Platinenrevision 
angesagt, wobei ich Dir dabei auch anraten würde die Vcc/GND-führung zu 
optimieren, anstatt nur an den entsprechenden Pinpaaren 100nF-Kerkos zu 
spendieren!

Die Programmierzange erinnert mich übrigens sehr an Tag-Connects 
Programmierkabel: http://www.tag-connect.com/
...die habe ich hier mal in einer Werbung gesehen und fande sie 
eigentlich ganz nett, nur der Preis schreckt natürlich ab.
Dazu finde ich die zwei Löcher neben den Pads, die zur Führung des 
Steckers nötig sind, etwas unpraktisch, durch sie kann man die Leitungen 
nur suboptimal von den Pads wegführen.
Wenn man dann noch den rastenden Stecker nimmt wird es völlig pervers - 
die riesigen vier Löcher für die Rastnasen machen meiner Meinung nach 
die meisten Vorteile wieder wett - nur die geringe Höhe ist natürlich 
immer noch ein Argument.

Deine Version finde ich klasse, werde mir so eine Zange wohl mal 
nachbauen - der einzige Nachteil durch die Zange ist halt, dass die Pads 
recht nah am Rand sitzen müssen, aber bei Platinen wo man auf einen 
ISP-Stecker verzichten muss, meist aus Platzgründen, kann man das ja 
arrangieren.
Wäre noch eine Idee in den Pads direkt Vias zu setzen, dank des recht 
groben Rasters sollte man so selbst bei einer zweilagigen Platine 
optimal mit den Signalen wegkommen.

Jedenfalls danke für die Inspiration!

Grüße
Sascha

[Tom Sawer (Gast)]

Hi Sascha!  Die vias sind auf der Außenseite direkt in den pads  :-).
Die Bohrungen nerven tatsächlich. beim nächsten Layout fallen sie weg.

Wenn man die klemme ändert, kann man ja noch weiter im die Platine rein. 
Ist ne Frage deiner Bastelmanie!

Evtl. Noch 1, 2 luftlinien für GND und VCC nachziehen? was meint ihr?

[Sascha W. (arno_nyhm)]

Mit Luftlinien meinst Du frei gespannte Drähte auf den bestehenden 
Platinen? Ja, das ist eine gute idee, ich weiß ja nicht wie all Deine 
Korrekturmaßnahmen zur Zeit aussehen, aber ich würde Dir empfehlen über 
alle Vcc/GND-Pinpaare einen 100nF-Kerko parallel zu schalten 
(0201-Kerkos sollten eigentlich direkt auf die Pins passen - sind 
natürlich etwas fummelig zu verarbeiten) und diese dann mit 
Kupferlackdraht (so dick wie möglich) zentral an Vcc/GND hängen.
Wenn das ganze haltfähiger/professionell sein soll, hilft eh nur ein 
Redesign der Platine - aber als Prototypen taugen sie mit diesen 
Modifikationen auf jeden Fall.

Zu den Löchern in den ISP-Pads: Mir ist noch etwas besseres eingefallen 
- ich werde bei meiner Variante wohl keine SMD-Pads nehmen sondern 
gleich THT-Pads, die ja direkt von jeder Lage aus kontaktierbar sind, 
und dazu nicht die stachligen Testpins sondern jene mit einer zentralen 
Spitze, so dürfte das, genau wie bei Dir mit zusätzlichen 
Lötzinn-Hügeln, sehr gut selbstzentrierend sein sowie auch ohne Zange, 
nur zum kurzen Programmieren, gut handhabbar!

Grüße
Sascha