Attiny84 verhalten unerklärlich

[Jakob H. (jakob_h)]

Hallo,

ich bin neu hier, also seht es mir bitte nach, wenn ich was vergesse.
Jedenfalls, zum Problem und damit dem Grund für diesen Post.


Ich arbeite an einer kleinen universellen Steuerungsplatine.
Dafür benutze ich einen Attiny 84, den ich mit einem original ATMEL 
AVRISP mkII über SPI programmiere zusammen mit Atmel Studio 7. Dieser 
muss eigentlich nur einen MOSFET für eine gewisse Zeit beschalten und 
während dessen schauen ob zu viel Strom fließt.
Zusätzlich habe ich einen einfachen Verpolungsschutz und einen +5V 
Spannungsregler verbaut.

Das Problem ist jedoch äußerst komisch.
Und zwar...

Der Attiny 84 tut nicht was er tun soll... ja, ja etwas genauer...

Die Spannungsversorgung ist einwandfrei und Entkopplungs-Kondensatoren 
sind auch eingebaut.
Programmieren des flashs und der fuses funktioniert allerdings nur ab 
und zu.
Dabei scheint es von völlig willkürlichen Faktoren abzuhängen ob sich 
der uC programmieren lässt oder nicht, z.B. einem 
Entkopplungs-Kondensator (100n) am RESET Pin oder den MOSI, MISO lines 
oder einem offenen Taster an selbigen.
In den Fällen, in denen das Lesen der Device Signatur fehlschlägt und 
damit auch das Programmieren und Lesen der Spannung am Target Device, 
ist die Spannung am RESET Pin sowohl wie den anderen auch ca. 300mV. 
Dies ist mir unerklärlich, da ich externe pullups verwende.
Aber seht selbst, die Schaltskizze befindet sich im Anhang.

Der Code befindet sich ebenfalls im Anhang.




Ich bin für jeden Hinweis dankbar.

MFG Jakob

[Christian S. (roehrenvorheizer)]

Hallo,

und was passiert, wenn Du noch einen Elko von 22 bis 47 uF an Pin 1 des 
tiny84 anschließt?

MfG

[Opti Mator (Gast)]

Jakob H. schrieb:
> Ich bin für jeden Hinweis dankbar.

ISP Takt klein genug gegenüber der Taktfrequenz des ATTiny84?

[Christian S. (roehrenvorheizer)]

Immerhin möchte innen drin eine Ladungspumpe los laufen.

MfG

[Opti Mator (Gast)]

Eine Stolperfalle bei "statistischen" Fehlern:

Wenn programmierender PC und Versorgung des Mikrokontrollers
zu unterschiedliche Massepotentiale haben können sie damit
die ISP Programmierung stören (keine eindeuigen Logikpegel).

[Tom (Gast)]

Es ist immer etwas ungünstig, wenn man an den Programmierleitungen (SCK, 
MISO, MOSI) noch zuviel eigene Schaltung dran hat.
Ich nehme mal an, das Du die Taster während der Programmierung in Ruhe 
läßt, aber der R16 ist wahrscheinlich zu niederohmig. Es kann auch nicht 
schaden C6 und C7 doch etwas zu redizieren.

Im Zweifelsfall mit dem Oszilloskop die Leitungen im 
(Programmier-)Betrieb anschauen und die Pegel prüfen.

[Julian B. (julinho)]

An den ISP Lines dürfen keine 100n hängen oder du willst nur mit 6kHz 
programmieren.
Mach mal das ganze Gedöns von den ISP-Leitungen ab.
Wenn an VCC 5V sind, müssen die auch an RST sein, sonst stimmt was mit 
der Beschaltung am RST-Pin nicht.

[Erwin D. (Gast)]

Julian B. schrieb:
> Wenn an VCC 5V sind, müssen die auch an RST sein, sonst stimmt was mit
> der Beschaltung am RST-Pin nicht.

Aber nicht bei der Programmierung (Reset)

[Jakob H. (jakob_h)]

Hey Leute,

erstmal vielen Dank für die zahlreichen Antworten in so kurzer Zeit.
Ich werde Sie eine nach der anderen abarbeiten.

1. Ich benutze den internen 8MHz RC-Oszi mit der standard mäßigen 
Verzögerung von + 64ms.

2. Ich habe noch nicht probiert einen 47uF Elko an Vcc zu hängen, es 
befindet sich lediglich ein 100n ceramic und 100uF elko vor dem 
Spannungsregler. Ich werde es jedoch ausprobieren.

3. Der ISP Takt ist 64kHz, also weit unter dem Max.

4. Der programmierende PC und das Target-board haben das selbe 
elektrische Potential, es besteht eine niederohmige Verbindung zwischen 
GND der Targetplatine und GND des USB-Steckers am AVRISP mkII.

5. Ich habe die Entkopplungs-Kondensatoren an RESET,MOSI und MISO 
entfernt und momentan scheint das Programmieren zu funktionieren, jedoch 
weis ich nicht ob das so bleibt. Der Code macht jedoch überhaupt nicht 
was er soll.
So leuchtet z.B. LED5 immer kurz grün, wenn immer ich einen Taster 
drücke (egal welchen) des weiteren leuchten manchmal, aber ohne 
erkennbares Muster, eine von 3 der einfachen LEDs auf (beim Drücken 
eines Tasters).

6. Ich kann verstehen, dass jegweilige Kapazität an SCK zu vermeiden 
ist, aber an RESET dürfte das doch kein Problem darstellen (was es tut).

MFG Jakob

[Jakob H. (jakob_h)]

Tom schrieb:
> Es kann auch nicht
> schaden C6 und C7 doch etwas zu redizieren.

Welchen Wert würdest du vorschlagen, damit der Taster trotzdem nicht 
osziliert.

MFG Jakob

[Bastian W. (jackfrost)]

Jakob H. schrieb:
> Tom schrieb:
>> Es kann auch nicht
>> schaden C6 und C7 doch etwas zu redizieren.
>
> Welchen Wert würdest du vorschlagen, damit der Taster trotzdem nicht
> osziliert.
>
> MFG Jakob

Wenn du noch nen Timer frei hast nimm die Softwareentprellung von Peda 
aus dem Forum.

Gruß JackFrost

[Peter D. (peda)]

Jakob H. schrieb:
> Entkopplungs-Kondensator (100n) am RESET Pin oder den MOSI, MISO lines
> oder einem offenen Taster an selbigen.

Das ist ne ganz blöde Idee, Entprellen macht man in Software.
Nur der Kondensator an Reset ist erlaubt, solange man nicht debuggen 
will.

[Florian (Gast)]

Jakob H. schrieb:
> aber ohne erkennbares Muster, eine von 3 der einfachen LEDs auf (beim
> Drücken eines Tasters).

Solch ein Phänomen kenne ich wenn man code in den tiny flashed! Wenn du 
das auch machst, wäre es sinnvoll den Code zu posten

[Jakob H. (jakob_h)]

Florian schrieb:
> Solch ein Phänomen kenne ich wenn man code in den tiny flashed! Wenn du
> das auch machst, wäre es sinnvoll den Code zu posten

Ich habe den Code im Uhrsprünglichen Post angehängt.

MFG Jakob

[Jakob H. (jakob_h)]

Bastian W. schrieb:
> Wenn du noch nen Timer frei hast nimm die Softwareentprellung von Peda
> aus dem Forum.
>
> Gruß JackFrost

Vielen Dank für den Tipp.

MFG Jakob

[Jakob H. (jakob_h)]

Florian schrieb:
> Jakob H. schrieb:
>> aber ohne erkennbares Muster, eine von 3 der einfachen LEDs auf (beim
>> Drücken eines Tasters).
>
> Solch ein Phänomen kenne ich wenn man code in den tiny flashed! Wenn du
> das auch machst, wäre es sinnvoll den Code zu posten

Würdest du mir erklären, woran das liegt oder wie der Fehler zu beheben 
ist?

Das wäre sehr nett.


MFG Jakob

[Jakob H. (jakob_h)]

Hallo zusammen, kleines Update:

Gute Nachrichten zuerst:

Der µC lässt sich mittlerweile zuverlässig programmieren, ich habe den 
100n am RESET wieder angehängt und die beiden Kondensatoren an MISO und 
MOSI entfernt.
Ein einfaches Testprogramm, mit dem ich alle LEDs einfach nacheinander 
aktiviere funktioniert auch.


Schlechte Nachrichten:

Ich kann mir nicht erklären, warum mein Hauptprogramm (das Angehängte) 
unwillkürlich macht was es will.
Des weiteren weis ich auch nicht wie ich geschickt eine 
Software-Entprellung in meine ISR einbauen kann, da ich den 
pinchange-Interrupt für beide Taster verwende.

Wenn sich jemand meinen Code anschauen würde, wäre ich sehr Dankbar.


MFG Jakob

[Stefan D. (mackie05)]

Welche Funktion erwartest Du von D2?

[Stefan F. (Gast)]

Software Entprellung macht man auch nicht in einer ISR. Ich glaube, 
multi-Threading mit endlichen Automaten (Zustandautomat, State machine) 
bringen Dich hier weiter.

[m.n. (Gast)]

Stefanus F. schrieb:
> Software Entprellung macht man auch nicht in einer ISR.

Stimmt. Am besten mit delay_ms(1000) im Hauptprogramm ;-)

[Jakob H. (jakob_h)]

Stefan D. schrieb:
> Welche Funktion erwartest Du von D2?

ESD Protection, alle Pins außer RESET haben intern eine Diode verbaut,
auf RESET wird diese standardmäßig weggelassen wegen "high voltage 
programming".
Es ist mir bewusst, dass diese diode dafür nicht optimal ist, ich hatte 
sie allerdings sowieso auf der bom.

MFG Jakob

[MiMa (Gast)]

m.n. schrieb:
> Stefanus F. schrieb:
>> Software Entprellung macht man auch nicht in einer ISR.
>
> Stimmt. Am besten mit delay_ms(1000) im Hauptprogramm ;-)

Hat durchaus seine (praktische) Berechtigung wenn man z.B. nur auf DEN 
EINEN Tastendruck wartet ;-)

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

Jakob H. schrieb:
> Des weiteren weis ich auch nicht wie ich geschickt eine
> Software-Entprellung in meine ISR einbauen kann, da ich den
> pinchange-Interrupt für beide Taster verwende.

Da bei dir ein Timer schon läuft, sollte es nur ein kleines Werk sein, 
PeDas Entprellroutine zu integrieren. Du hast beim PC Interrupt nämlich 
mehrere Problemchen:
1. wird der PC Interrupt sowohl bei der fallenden als auch bei der 
steigenden Flanke getriggert. Jeder Tastendruck erzeugt also selbst bei 
einem idealen, prellfreien Taster zwei Aufrufe der ISR.
2. gibt es ja ohne zusätzliche Hardware keine idealen Taster. Da kann es 
schon mal sein, das du beim Drücken 4 oder 7 Flanken auslöst, die vom 
AVR alle brav ausgewertet werden. Sowas eignet sich als elektronischer 
Würfel, aber nicht zur gezielten Steuerung.

https://www.mikrocontroller.net/articles/Entprellung

[M. K. (sylaina)]

MiMa schrieb:
> Hat durchaus seine (praktische) Berechtigung wenn man z.B. nur auf DEN
> EINEN Tastendruck wartet ;-)

Nein, auch dann nicht.

[MiMa (Gast)]

M. K. schrieb:
> MiMa schrieb:
>> Hat durchaus seine (praktische) Berechtigung wenn man z.B. nur auf DEN
>> EINEN Tastendruck wartet ;-)
>
> Nein, auch dann nicht.

Hm ja okay. 1000ms sind zu lang. Zum Rest stehe ich allerdings ;-)

Wenn ich nur auf den einen Tastendruck warte, dann macht es absolut 
keinen Unterschied ob der uC 100ms in einer delay Schleife wartet, oder 
eben 100ms in der while wartet bis der Timer abgelaufen ist.