printf -> stdout und _delay_ms() bringen At90CAN zum Reset

[Daniel P. (callmed)]

Hallo,

hab nun zwei Tage gebraucht um festzustellen, dass die Verwendung von 
STDOUT mittels printf auf USART1 und die Verwendung von _delay_ms(750) 
(aus util/delay.h) meinen AT90CAN128 zum Reset bringen.

Egal welche Zeile zu erst erreicht wird, das Delay oder die Printf, ab 
dieser Zeile startet der AT90CAN128 von Neuem.

Hatte von euch schon jemand dieses oder ähnliches Problem mit einem uC 
und gibt es eine Lösung?
Ich habe die _delay_ms mittels Timer0 umgehen wollen, leider wurde auch 
hierbei ein RESET ausgelöst - bin Momentan ratlos und brauche dringend 
einen TIPP bzw. eine Lösung, da ich bei diesem Projekt zu einem Ende 
kommen muss.

Danke schon mal im Vorraus,

[Karl H. (kbuchegg)]

Bei dir scheint irgendetwas anderes faul zu sein, wenn du so gut wie 
immer einen Reset bekommst, scheinbar egal was du machst.

Ein eingeschalteter Watchdog könnte aber das Verhalten ohne weiteres 
ganz leicht erklären. Denn ganu das ist seine Aufgabe: den µCzu 
resetten, wenn er nicht regelmässig zurückgepfiffen wird.

Also würde ich zuallererst mal die Watchdog Fuse kontrollieren.

[holger (Gast)]

Ich tipp auf RAM am Ende.

[Klaus W. (mfgkw)]

Ich tippe auf SW-Fehler oder HW-Fehler, oder user error.

[Daniel P. (callmed)]

holger schrieb:
> Ich tipp auf RAM am Ende.

Gibt es eine Möglichkeit diese Vermutung zu testen?

[Daniel P. (callmed)]

Klaus Wachtler schrieb:
> Ich tippe auf SW-Fehler oder HW-Fehler, oder user error.

Zu SW-Fehler: Port,Timer und USART Init
danach kommt printf("Board Online");, die while(1) mit PORTD ^= 
(1<<PD4);, was die LED ein/ausschalten gefolgt von _delay_ms(500);.
Nicht wirklich viel und denke mal hierbei wird wohl auch kein Fehler 
passiert sein.
Das blinken sowie die printf-Ausgabe für sich (jeweils das andere 
Ausgeklammert) funktioniert ohne Probleme - dadurch würd ich SW-Fehler 
nochmals bezweifeln.

Zu HW-Fehler: Du meinst AT90CAN128 ist defekt oder die Pheripherie? 
Beides wäre sehr ungünstig :-(

Zu User-error: Erklär du mal was du damit meinst ...

[Daniel P. (callmed)]

Karl heinz Buchegger schrieb:
> Bei dir scheint irgendetwas anderes faul zu sein, wenn du so gut wie
> immer einen Reset bekommst, scheinbar egal was du machst.
>
> Ein eingeschalteter Watchdog könnte aber das Verhalten ohne weiteres
> ganz leicht erklären. Denn ganu das ist seine Aufgabe: den µCzu
> resetten, wenn er nicht regelmässig zurückgepfiffen wird.
>
> Also würde ich zuallererst mal die Watchdog Fuse kontrollieren.

HI, danke für den Tipp! Leider negativ, jede FKT für sich läuft ohne 
Probleme auch mehrere Minuten lang - also wenn die Kombination der 
beiden keine Fuses setzt ist der WATCHDOG wohl aus.

[Klaus W. (mfgkw)]

Daniel Ple schrieb:
> Erklär du mal was du damit meinst ...

Ich meine, daß man bei so einer Wischiwaschi-Beschreibung keine
vernünftige Antwort erwarten kann, daher meine Wischiwaschi-Antwort.

Daniel Ple schrieb:
> Zu SW-Fehler: Port,Timer und USART Init
> danach kommt printf("Board Online");, die while(1) mit PORTD ^=
> (1<<PD4);, was die LED ein/ausschalten gefolgt von _delay_ms(500);.
> Nicht wirklich viel und denke mal hierbei wird wohl auch kein Fehler
> passiert sein.
> Das blinken sowie die printf-Ausgabe für sich (jeweils das andere
> Ausgeklammert) funktioniert ohne Probleme - dadurch würd ich SW-Fehler
> nochmals bezweifeln.

Nachdem du deiner Meinung nach alles ganz einfach und richtig
geschrieben hast, kann es ja keinen Fehler geben :-)


Mit anderen Worten: ohne das Programm kannst du hier stundenlang
Leute rätseln lassen, ohne daß etwas dabei rauskommt, außer
verschwendeter Zeit.

Die Standardaufgabe für dich wäre:
- soweit reduzieren wie möglich, daß der Fehler noch auftritt
- dann das Programm zeigen, nicht eine luschige Beschreibung,
  was es deiner Meinung nach macht.

[Daniel P. (callmed)]

Klaus Wachtler schrieb:
>
> Ich meine, daß man bei so einer Wischiwaschi-Beschreibung keine
> vernünftige Antwort erwarten kann, daher meine Wischiwaschi-Antwort.
>
>
> Nachdem du deiner Meinung nach alles ganz einfach und richtig
> geschrieben hast, kann es ja keinen Fehler geben :-)
>
>
> Mit anderen Worten: ohne das Programm kannst du hier stundenlang
> Leute rätseln lassen, ohne daß etwas dabei rauskommt, außer
> verschwendeter Zeit.
>
> Die Standardaufgabe für dich wäre:
> - soweit reduzieren wie möglich, daß der Fehler noch auftritt
> - dann das Programm zeigen, nicht eine luschige Beschreibung,
>   was es deiner Meinung nach macht.


Schon klar, sry. Anbei die Datei. - DANKE

[Klaus W. (mfgkw)]

UCSR1B  |=  (1<<RXCIE1)  |  (1<<TXCIE1)  |  (1<<RXEN1)  |  (1<<TXEN1);

Kann es sein, daß da eine ISR ausgelöst wird (später), die es nicht 
gibt?

[Daniel P. (callmed)]

Klaus Wachtler schrieb:
> UCSR1B  |=  (1<<RXCIE1)  |  (1<<TXCIE1)  |  (1<<RXEN1)  |  (1<<TXEN1);
>
> Kann es sein, daß da eine ISR ausgelöst wird (später), die es nicht
> gibt?

Klaus ... DANKE !!!

Ich hab die Interrupt RX und Tx rausgenommen und nun funktioniert ES - 
BEIDES.

Danke nochmal für die schnelle Hilfe, kann nun endlich weitermachen.

[Klaus W. (mfgkw)]

Mach mal weiter, ich gehe schnarchen...