ATMEGA startet ab und an nicht

[Alec T. (803)]

Hallo zusammen,

ich hab hier eine Schaltung mit ATMEGA328P. Die Controller laufen nach 
anlegen von VCC manchmal nicht an. Wenn er aber erstmal läuft läuft er 
100% zuverlässig ohne abstürze oder sonstige Probleme.
Ein Bluetooth-Modul das mit auf der Platine an derselben 
Versorgungsspannung sitzt startet hingegen zuverlässig jedesmal.

Der uC läuft über den internen Oszillator auf 8Mhz mit 64CLK 
aufstartzeit. Brownout detektor auf 2,7V. Blockkondensator 100nF an VCC. 
Inzwischen auch 10k gegen VCC am Reset (das hat aber überhaupt nix 
geholfen). Das Programm hab ich testweise schon auf das minimum gekürzt 
(s.u.)

Ich habe drei kleine Schaltungen, zwei auf Platine, eine auf Steckbrett. 
An allen kann ich den Effekt (mehr oder weniger ausgeprägt) beobachten. 
Also gehe ich davon aus das es etwas systematisches sein muss.

Wenn ich den Controller mit 5V aus einem Linearregler (100mA) versorge 
der nach einem Schaltregler (36V->7,2V) sitzt startet der Controller nur 
so in etwa jedes zweite Mal nach Anstecken der versorgung (36V Akku).
Wenn ich den Linearregler aus einem Labornetzteil versorge startet der 
uC so in etwa 90% der Fälle. Bei direkter Versorgung aus dem 
Labornetzteil startet er fast immer, aber ich krieg es mit wildem 
Laborkabel ein und ausstecken immer noch dahin das er doch mal nicht 
anläuft.

Offensichtlich hat das Ganze also irgendwie mit der Versorgung zu tun, 
allerdings hab ich mir die Spannung am Oszi (okay ich weiss nur so grob 
wie man das bedient) angeschaut und sieht für mich eigentlich alles sehr 
sauber und stabil aus, ist auch sofort da.
Ich dachte der Brownout detektor sollte dafür sorgen das Probleme 
aufgrund der Spannungsversorgung nicht auftreten?

Jemand ne idee was die Ursache sein könnte oder wie ich dem ganzen auf 
die Spur kommen kann?
Was mich am meisten irritiert ist das ich es selbst am 
Profi-Labornetzteil hinkrieg?!

Danke für eure Hilfe.



Testprogramm:

#define REGISTER_BIT(rg,bt) ((volatile _io_reg*)&rg)->bit##bt
#define IO_LED_RED            REGISTER_BIT(PINC,5)
#define IO_LED_RED_DIR        REGISTER_BIT(DDRC,5)
#define IO_LED_RED_OUT        REGISTER_BIT(PORTC,5)

int main(void)
{
  uint8 u8CpuStatus = MCUSR;
  MCUSR = 0;
  wdt_disable();

  IO_LED_RED_DIR = PIN_DIR_OUT;
  while(1)
  {
    IO_LED_RED_OUT = !IO_LED_RED_OUT;
    _delay_ms(500);
  }
}

[Magic S. (magic_smoke)]

Versuch mal eine längere Startzeit oder BOD höher. 10nF gegen Masse an 
Reset können auch helfen, oder falls so eine Modifikation noch geht, 
einen externen Quarz.

[Falk B. (falk)]

@ magic smoke (magic_smoke)

>Versuch mal eine längere Startzeit oder BOD höher. 10nF gegen Masse an
>Reset können auch helfen, oder falls so eine Modifikation noch geht,
>einen externen Quarz.

Quark. Die Einstellungen vom OP sind voll OK, der AVR läuft damit solide 
an. Das Problem liegt woanders. Vielleicht spinnt der angesteckte 
Programmieradapter?

[Magic S. (magic_smoke)]

> der AVR läuft damit solide an.
Achsooo, sorry, das wußte ich nicht.

>>> Die Controller laufen nach anlegen von VCC manchmal nicht an.

[holger (Gast)]

>Brownout detektor auf 2,7V.

Auch wenn andere anderer Meinung sind könnte man da ruhig
mal 4,3V einstellen.

AVCC und alle GND sind angeschlossen?

[Alec T. (803)]

Ja, der ADC wird benutzt und ist nach Standard-Atmel-Empfehlung 
beschaltet. Keine offenen VCC oder Masse-Pins.

Das interessante: Das Problem tritt OHNE Programmieradapter auf. Mit 
angestecktem Programmieradapter (STK500) laufen die Controller 
zuverlässig los. Nur VCC bypassen hilft aber wie gesagt leider nicht und 
die 10k am Reset habe ich ja. Die übrigen Pins (MISO,MOSI,CLK) sind auf 
den Schaltungen offen, auf dem Steckrett hängt da ein LC-Display (CS 
usw) dran...

Ich werde als nächstes wohl erstmal die vorgeschlagene Kapazität am 
reset versuchen, vielleicht sind da ja hochfrequente Anteile von 
irgendwo her die ich auf dem Oszi nicht gesehen habe?
Und den Brownout Level schraub ich auch mal um.

Den Watchdog benutz ich bislang nicht, ich probier denke ich auch mal ob 
ich den benutzen kann falls ich die ursache nicht finde zumindest 
zuverlässig starten zu können, auch wenn das eher unbefriedigend wär...

[Falk B. (falk)]

@Alec Tanner (803)

>Das interessante: Das Problem tritt OHNE Programmieradapter auf. Mit
>angestecktem Programmieradapter (STK500) laufen die Controller
>zuverlässig los.

Klingt nach einem Masseproblem. Hast du die mal überprüft? Kommt die 
wirklich vom Netzteil zum Controller?

[Anja (Gast)]

Alec Tanner schrieb:
> Offensichtlich hat das Ganze also irgendwie mit der Versorgung zu tun,

So etwas ähnliches hatte ich schon mit einem USB->TTL-Adapter.
Die halblebige Speisung über den (hochohmigen) USB hat verhindert daß 
der RESET korrekt abgearbeitet wurde.

Gruß Anja

[cortexuser (Gast)]

Bei einem anderen AtMega hatte ich das gleiche Problem, wenn ich direkt 
nach der main() eine Init-Funktion aufgerufen habe. Eine Wartezeit mit 
einer for-Schleife hat geholfen. Das Problem lag vll wo anders, aber es 
hat so zuverlässig funktioniert.

[Magic S. (magic_smoke)]

Einfach mal einen 10nF fliegend zwischen GND und Reset löten und schauen 
ob der das Problem löst.

[Sébastien M. (sebi211)]

Ich würde mal noch das return 0 in dein Programm einfügen.