Atmega324A Probleme bei FET Steuerung

[Schasa (Gast)]

Hallo zusammen,

habe mir am Wochenende einen Cube aufgebaut mit der dazu benötigten 
Hardware. Als Controller verwende ich einen Atmega324A. PortC soll von 8 
N-Kanal MosFets das Gate ansteuern und somit die LEDs auf Masse ziehen.

Das funktioniert bei 6 Kanälen und bei PC0 und PC1 nicht. Erst wenn ich 
mit dem Multimeter an das Gate gehe, löschen sich die LEDs.

Ich habe in einem anderen Threat etwas von Pull Down Widerstände gelesen 
(1MOhm) die an das Gate geschlossen werden soll.

Gibt es noch eine andere Ursache?

FET ist der hier: IRLML2502

Der Schaltplan ähnelt der dem LED-Cube Projekt hier im Forum.

Ich bedanke mich schon einmal...

Mfg
Schasa

[Hubert G. (hubertg)]

Das sieht so aus als wären die beiden Pin nicht als Ausgang geschalten.
Software selbst geschrieben?

[Schasa (Gast)]

Ja aber bis jetzt halt nur ein simples Ein- und Ausschalten des Cubes. 
Programmiere PortC als Ausgang mit DDRC = 0xFF. Das klappt wie gesagt 
nur bei PC0 und PC1 nicht. Im Datenblatt habe ich auch keine speziellen 
Funktionen für diese Pins finden können. JTAG läuft über andere Pins an 
PortC und bereits über die Fuses ausgeschaltet.

Bin aber auch ein Neuling in Sachen Programmierung.

[Hubert G. (hubertg)]

Zeig mal dein Programm, mir fällt da nur noch I2C ein das auf den beiden 
Pin liegt.

[g457 (Gast)]

> PortC

JTAGEN?

HTH

[Schasa (Gast)]

Wie gesagt bis jetzt nur das Programm zum testen der Hardware.

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

int main(void)
{
        DDRA = 0xFF;
  DDRC = 0xFF;
  DDRD = 0xFF;

  int i;
  int j;
  i = 200;
  j = 1000;

     while(1)
     {
    PORTA = 0b11111111;
    PORTD = 0b11111111;
    PORTC = 0b11111111;
    _delay_ms(j);
    PORTA = 0b11111111;
    PORTD = 0b11111111;
    PORTC = 0b00000000;
    _delay_ms(j);
     }
}

Kurze Erläuterung was ich mir bei dem Programm gedacht habe. Habe alle 
benutzten Ports als Ausgang definiert. Dann in einer Endlosschleife 
einfach alles eingeschalltet und mit einem Delay wieder ausgeschaltet. 
Beim Ausschalten bleiben die Ebenen von PC0 und PC1 an. Können gelöscht 
werden, indem ich da bspw. ein Multimeter anschließe.

Nach mehreren Threats hier doch Pull-Up Widerstände an den Gates? Kann 
das jetzt leider nicht testen da ich keine SMD Bauteile hier habe.



Ja der Controller besitzt an PortC eine JTAG Schnittstelle.. bzw. im 
Datenblatt steht etwas von Jtagen...

[g457 (Gast)]

> Ja der Controller besitzt an PortC eine JTAG Schnittstelle.. bzw. im
> Datenblatt steht etwas von Jtagen...

Hast du JTAGEN gelöscht? Per Default ist das an.

HTH

[Schasa (Gast)]

Ja habe ich. Ich programmiere mit dem JTAG ICE MKII aber über ISP. AVR 
STudio 5 benutze ich als Software und dort unter Fuses konnte man JTagen 
deaktivieren. PC0 und PC1 haben aber auch nichts mit dem Jtagen zu tun 
laut Datenblatt.

[Dedmont (Gast)]

hmm...dann musst du irgendwo wohl geschlampt haben

[Schasa (Gast)]

Da ich ebenfalls keine Erklärung habe, versuche ich es mit den Pull Down 
Widerstände am Gate. Löte in die Schaltung einfach mal bedrahtete 
Bauelemente und teste es.

Danke soweit!!

[Schasa (Gast)]

So muss den hier noch einmal ausgraben...

Habe heute an den Gates der Fets 1MOhm Pull Down Widerstände gelötet.
Vorher gingen zwei PC1 und PC2 nicht. Jetzt funktioniert PC2 aber PC1 
nur teilweise.

Der Würfel schaltet zweimal PC1 Ein und Aus und danach bleibt der FET 
aus.

Jetzt frage ich mich.. Hat der Atmega324A irgendwelche Funktionen an PC0 
und PC1?
Ich komme hier einfach nicht weiter.

Wenn ja wie deaktiviere ich die Funktion?

[Hubert G. (hubertg)]

Abgesehen das du in deinem Testprogramm nur PortC umschaltest und die 
anderen nicht, liegt auf PC0 und PC1 nur TWI.
Hast du den Code hier herein kopiert oder abgeschrieben?

[Schasa (Gast)]

Also hatte mich verschrieben. PC0 und PC1 machen Probleme. Habe an den 
Gates jetzt Pull-Down Widerstände. Keine Änderung. PC0 und PC1 stehen 
für I2C Bus zur Verfügung wie ich im Datenblatt gesehen habe. Kann das 
Probleme machen?

Programm ist kopiert.

Was macht das Programm jetzt?

Habe einfach ein paar Muster programmiert. Das Muster funktioniert 2-3 
Zyklen danach passiert an PC0 nix mehr. Ich vermute das es mit SCL und 
SDA zu tun hat.

DOch keine Lösung!!

[holger (Gast)]

>Habe einfach ein paar Muster programmiert. Das Muster funktioniert 2-3
>Zyklen danach passiert an PC0 nix mehr. Ich vermute das es mit SCL und
>SDA zu tun hat.

Ich vermute das es mit deinem unbekannten Programm zu tun hat.

[Thomas (kosmos)]

du hast ja 2 Zähler die runtergezählt werden, was passiert wenn diese 
unter 0 gehen werden Sie wieder auf 200 bzw. 1000 zurückgesetzt?

In Assembler passiert es ohne Zurücksetzung das es halt nicht wieder von 
200 startet sondern von 255 gerade bei verschachtelten schleifen kann es 
da leicht passieren das mans nicht bemerkt.

[Schasa (Gast)]

Mhh das weiß ich nicht @Thomas O.

Habe den Atmega324A gegen einen Atmega32 getauscht und siehe da. Die 
Ebenen lassen sich ganz  normal schalten. Ich habe keine Ahnung warum 
PC0 und PC1 bei dem Atmega324A so Probleme verursacht haben.

Laut Datenblatt liegt an diesen Pin der I2C-Bus. Der soll aber angeblich 
nicht aktiviert sein und muss erst aktiviert werden.

Naja... es läuft unerklärlicherweise.. :)

Danke für die Bemühungen hier im Threat.

[Markus Buschhoff (Gast)]

Sehr interessant, ich habe hier auch Probleme mit dem 324a. Auch bei mir 
lief (und läuft) einfachster Programmcode auf dem MEGA32 problemlos. Ich 
vermute, AvrStudio 5 oder die Toolchain versaut das Memory mapping.

Beispiel: void main() setzt ein Bit in DDRA und PORTA und bringt so eine 
LED zum leuchten. Das klappt immer im MEGA32, im 324a bekomme ich die 
LED zum blinken (also Neustart des uC, manchmal auch nur mit Oszi 
richtig zu sehen), wenn ich nur genügend ungenutzen Library-Code 
hinzulinke. An einem Punkt (etwa 3410 Bytes Programmcode) flippt der uC 
aus, egal welche Libs. Aus den Libs wird nicht ein einziger Befehl 
tatsächlich ausgeführt.

Nun werde ich das mit Studio 4 testen.

[Markus Buschhoff (Gast)]

So, ein Nachtrag: Mit AVR-Studio 4 und gleichem Source-Code (aber: 324P 
gewählt, weil der 324A da nicht existiert) funktioniert alles. Hat mich 
einen Tag gekostet, diese Lektion.

Werde nächste Woche mal schauen, was da genau das Problem ist. 
Vielleicht hat ja schon mal jemand eine Idee...?

[Markus Buschhoff (Gast)]

Und ein letzter: AVR-Studio 5 mit 324P als Target geht auch. Mh.

[Simon K. (simon)]

Na was steht denn drauf auf dem Prozessor?! Es gibt AFAIK nur noch den 
ATmega324P, da der moderner hergestellt wird. Der ATmega324 ist obsolet.

[Markus Buschhoff (Gast)]

Es steht drauf ATMEGA324A - PU, Farnell Best. Nr. 1841611. Auch die ID 
des Chips bezeugt das. Der 324A ist bei Farnell durchaus noch 
bestellbar. Vielleicht ein Restbestand.

[Markus Buschhoff (Gast)]

Mein Riecher mit dem Memory Mapping war richtig. AvrStudio 5 mappt das 
RAM auf die Adresse 0x60, richtig wäre aber 0x100.

Siehe auch: 
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=107811

Abhilfe: Entweder den 324P einstellen (aber dann Probleme beim 
Debuggen), oder den 324A einstellen und Linker-Option "-Tdata 0x800100" 
setzen.

Außerdem sollte man anschließend nach der Re-Programmierung der MCU 
unbedingt das Gerät komplett von der Spg.Versorgung trennen. Ein Reset 
hat bei mir (reproduzierbar) nicht geholfen, das Teil korrekt neu zu 
starten.