Hallo,
ich habe einen ATMega644. Wenn am RX Pin ein zyklisches Signal anliegt,
fängt der Controller an zu spinnen; Entweder stürzt er komplett ab, oder
es wird eine Variable einfach mit einem Wert beschrieben!
Ich habe das Problem auf folgendes Testprogramm reduzieren können:
1
#include<avr/io.h>
2
#include<stdlib.h>
3
#include"m50530.h"
4
#include"global.h"
5
#include<util/delay.h>
6
7
8
9
intmain(void)
10
{
11
int16_ttestVar=0;
12
charstring[20];
13
LCDInit();
14
PORTD=1;
15
while(1)
16
{
17
testVar++;
18
_delay_ms(30);
19
cls();
20
LCDWrite(itoa(testVar,string,10));
21
}
22
}
Das Display ist vollständig am Port A.
Wenn ich das Programm starte, wird auf dem Display wie erwartet schnell
hochgezählt. Wenn ich nun aber ein Signal über einen FT232 zum
Controller schicke (zum Beispiel 7200 BAUD, 10 Byte / 25 ms) fängt er an
zu spinnen; Die hochzählende Variable ändert etwa alle 15 Sekunden ihren
Wert (wird gelöscht oder springt auf irgend einen anderen Wert).
Das Problem tritt nur am RX Pin auf, auch wenn wie in diesem Fall der
UART noch nichtmal eingeschaltet ist. Senden von Daten über den UART
funktioniert vollständig, den Controller ausgetauscht habe ich auch
schon; gleiches Problem vorhanden.
Kann mir jemand weiterhelfen?
In den FUSES sieht alles richtig aus. Ich habe den Pin zu seinen
Nachbarpins durchgeklingelt: Kein Kurzschluss.
Ich glaub die Controller sind beide fehlerhaft.
Oliver J. schrieb:> Daniel schrieb:>>Ich glaub die Controller sind beide fehlerhaft.> Zeig mal die Schaltung.> Hast du überall die üblichen 100nF dran?>> Gruß Oliver
Selbst verständlich.
Zur Schaltung gibts nicht viel zu erzählen. Display an Port A, 20 MHz
Quarz + 15 pF Kondensatoren.
Der FT232 ist nur mit der Masse mit dem Controller fest verbunden. FT232
erhält Spannung über USB, Atmel erhält Spannung über
Programmierinterface MK2.
Durch eine steckbare "Pinleitungen" verbinde ich den TX des FT232 mit
dem RX des ATMega. Dadurch kann ich auch erkennen, dass der Controller
nur abstürtzt, wenn das Signal am RX Pin anliegt. Bei den anderen IO
Pins stört ihn das angelegte Signal nicht.
Signal ist mit dem OSCI gemessen: Normales 5 Volt Signal. Der Abstuz
passiert auch bei anderen BAU Raten (zum Beispiel 500000 BAUD).
Thema : debuggen. Die Applikation istschon viel zu komplex. Der Fehler
kann etwas triviales sein. Also schmeiss mal das unnoetige raus, bis
der fehler nicht mehr auftritt.
Daniel schrieb:> PORTD=1;
Kann es zufälligerweise sein, das du irgendwo anders PORTD als Ausgang
definierst? Dann würdest du mit obigem Befehl den RX-Pin auf 1 setzen
(VCC), was, wenn der FTDI sendet, ein klassischer Kurzschluss währe,
Ergo VCC zu tief, BOD spricht an, MC resetet.
Nimm den Befehl mal raus oder definiere im DDRD den Pin eindeutig als
Eingang und schaue obs dann immer noch abstürzt.
Gruss Stefan
Hallo !
ich hatte mal so ein ähnliches Problem, nachdem der RX Eingang nicht
beschaltet war, nachdem ich den USB Serielladapter (mcp2200) abgezogen
hatte.
Habe dann einfach den PullUp eingeschaltet und der Pin hatte einen
definierten Pegel.
Ein einfacher 10k - 47k PullUp nach Vcc ist auch ein Möglichkeit.
Hi
>Kann es zufälligerweise sein, das du irgendwo anders PORTD als Ausgang>definierst? Dann würdest du mit obigem Befehl den RX-Pin auf 1 setzen>(VCC) was ein klassischer Kurzschluss währe, Ergo VCC zu tief, BOD>spricht an, MC resetet.>Nimm den Befehl mal raus oder definiere im DDRD den Pin eindeutig als>Eingang und schaue obs dann immer noch abstürzt.
Wenn das RXEN-Bit gesetzt ist hat die UART den PIN unter Kontrolle. Da
kannst du auf die Portregister zugreifen wie du willst. Wenn es
allerdings nicht gesetzt ist kann es Probleme geben.
MfG Spess
Hallo alle!
Delta Oschi schrieb:> Thema : debuggen. Die Applikation istschon viel zu komplex. Der Fehler> kann etwas triviales sein. Also schmeiss mal das unnoetige raus, bis> der fehler nicht mehr auftritt.
Naja, was ist daran denn komplex und was soll ich da noch rausschmeißen?
Das Display und die Zählvariable benötige ich um zu sehen, ob der Fehler
auftritt.
Stefan M. schrieb:> Daniel schrieb:>> PORTD=1;>> Kann es zufälligerweise sein, das du irgendwo anders PORTD als Ausgang> definierst? Dann würdest du mit obigem Befehl den RX-Pin auf 1 setzen> (VCC), was, wenn der FTDI sendet, ein klassischer Kurzschluss währe,> Ergo VCC zu tief, BOD spricht an, MC resetet.> Nimm den Befehl mal raus oder definiere im DDRD den Pin eindeutig als> Eingang und schaue obs dann immer noch abstürzt.>> Gruss Stefan
Das ist in meinen Augen auch der naheliegenste Grund des Fehlers, aber
weder DDRD, noch PORTD oder PIND werden in irgendwelchen Bibliotheken
benutzt.
DDRD=1 bezweckte den internen Pullup Widerstand einzuschalten. Die Pins
sind ja automatisch als Eingang gesetzt, daher habe ich dies nicht
nochmal extra implementiert.
Uwe S. schrieb:> Habe dann einfach den PullUp eingeschaltet und der Pin hatte einen> definierten Pegel.
Hab ich doch auch schon gemacht. ;-)
Ich hab jetzt nochmal ein bisschen weiterprobiert: Am TX Pin sende ich
jetzt mit der gleichen BAUD Rate und gebe das Signal auf den RX Pin:
Kein Absturz. Daraufhin habe ich neben der gemeinsamen Masse auch die 5V
Verbindungen von FT232 und µC zusammengeschlossen, und den Controller
wieder mit dem TX des FT232 verbunden: Programm stürzt ab. Auf dem
Oszilloskop sieht das Signal des FT232 sogar noch sauberer aus, als das
TX Signal des Mikrocontrollers.
Nun weiß ich wirklich nicht mehr weiter... :-(
Daniel schrieb:> ...> Ich hab jetzt nochmal ein bisschen weiterprobiert: Am TX Pin sende ich> jetzt mit der gleichen BAUD Rate und gebe das Signal auf den RX Pin:> Kein Absturz.
OK
> Daraufhin habe ich neben der gemeinsamen Masse auch die 5V> Verbindungen von FT232 und µC zusammengeschlossen, und den Controller> wieder mit dem TX des FT232 verbunden: Programm stürzt ab.> Auf dem> Oszilloskop sieht das Signal des FT232 sogar noch sauberer aus, als das> TX Signal des Mikrocontrollers.
?? Masse richtig verbunden ??
Zeig doch mal einen Schaltplan, und wo du gemessen hast!
Gib das TX vom Controller mal auf den FT und schau ob die Daten am PC
ordentlich ankommen.
Sascha
Daniel schrieb:> Der FT232 ist nur mit der Masse mit dem Controller fest verbunden. FT232> erhält Spannung über USB, Atmel erhält Spannung über> Programmierinterface MK2.
Falls du mit "MK2" den AVR ISP mk II meinst: Das wird nichts, dessen
"Plus"-Leitung taugt nicht zur Stromversorgung des Controllers.
Sascha Weber schrieb:> ?? Masse richtig verbunden ??> Zeig doch mal einen Schaltplan, und wo du gemessen hast!
Hab grad zum geschätzten 10. Mal überprüft: Ja, die Massen sind korrekt
verbunden. Messen tu ich direkt am RX Pin des µC. Wahlweise verbinde ich
diesen mit dem TX des µC oder mit dem TX des FT232.
Bei Eagle hab ich den FT232R nicht gefunden, ich habe ihn aber nach der
"USB Bus Powered Configuration" (siehe Anhang) angeschlossen.
Die Masse geht statisch zum Mikrocontroller, alle anderen Verbindungen
stecke ich mit solchen "Pinleitungen".
> Gib das TX vom Controller mal auf den FT und schau ob die Daten am PC> ordentlich ankommen.
Ja, die Daten kommen beim PC an, und was ich noch nicht erwähnt habe:
Der UART Empfänger des µC "funktioniert" auch mit dem FT232. Ich habe
ein 10 Byte großes Protokoll (Mit Start- Stop-, und Prüfsummenbyte) und
die Daten kommen im µC korrekt an. Leider stürzt er dabei andauernd ab.
Daraufhin hab ich das Programm auf das oben gepostete gekürzt und er
stürzt weiterhin ab.
Konrad S. schrieb:> Falls du mit "MK2" den AVR ISP mk II meinst: Das wird nichts, dessen> "Plus"-Leitung taugt nicht zur Stromversorgung des Controllers.
Also bei mir ging das die letzten 2 Jahre ganz gut mit der
Spannungsversorgung. Habs wie gesagt ja auch mit der direkten USB 5V
Leitung probiert. Hilft leider nichts.
Hallo,
20Mhz Quarz...
sind nur bei einem 100 prozentigen Layout ok.
Solltest du auf einen Steckboard oder Ähnlichen arbeiten, kann es schon
mal zu Abstürzen kommen. Nimm mal z.B. ein 11,059000 Mhz zum Testen her.
Gruß xmega
Thread beobachten
Seitenaufteilung abschalten