Hilfe bei CAN-Bus Projekt

[kevin m. (kevinm)]

Guten Abend,

ich habe ein Problem mit meinem CAN-Bus Projekt. Beschäftige mich schon 
seit langen mit dem Atmega und den MCP2515. Leider ist jetzt das Projekt 
schon ziemlich groß geworden für einen Atmega und der Quellcode schon 
ziemlich lang. Es handelt sich bei meinem Projekt um eine universale 
CAN-Bus Schnittstelle zwischen PC und Auto. Atmega644, MCP2515 über SPI, 
MCP2551 High Speed Transceiver und ein TFT Screen. Das Empfangen 
funktioniert einwandfrei.

Das Problem: Ich Sende die Canbus Nachrichten über einen FTDI USB Chip 
mit 921600 bit/s zum PC ständig sobald Botschaften eingetroffen sind. 
Nun möchte ich gleichzeitig Nachrichten Senden. Habe dazu ein VB 
Programm entworfen das in einer intervall die Nachrichten zum 
Mikrocontroller sendet. Sende ich gleichzeig eine Nachricht bleibt der 
Mikrocontroller irgendwann mal hängen. Sende ich 3 Nachrichten neben dem 
Empfang gleichzeitig, bleibt er schon nach kurzer zeit ( ca 20 Sek.  ist 
aber unterschiedlich) hängen. Ich glaube es liegt an einem UART PUFFER 
Überlauf, aber warum? Kann mir jemanden Tips zum debuggen für ein 
solches ereignis geben?

Ich habe mein Projekt im anhang. Vll kann sich jemand mein Code 
anschauen ob das alles so im groben in Ordnung ist?

Viele Dank schonmal.

[Georg I. (dschi-ai)]

Vielleicht überforderst du den kleinen Kerl, bei 16MHz und 0,9MBaud hast 
du nur noch 170 Takte, das ist für CAN, UART und TFT nicht wirklich viel

[Juergen G. (jup)]

Ich hab auch mal sowas gemacht, bin aber dann auf einen uC mit CAN 
umgestiegen. Inzwischen ist es ein uC mit CAN und USB.

Dein Projekt ist super um zu verstehen was da alles vor sich geht.
Spaeter dann beim realistischen Einsatz wirst Du immer wieder ein 
Feature  vermissen und es implementieren wollen. Dann bist Du schnell an 
der Grenze des in Software "gleichzeitig" machbaren.

[Bronco (Gast)]

Ob der µC überfordert ist oder nicht, ist erst mal nicht das Problem.
Das Problem ist, daß das Programm hängen bleibt, und das kann nur ein 
Programmierfehler sein.
Hier hilft nur Debuggen...

Was passiert denn im Fehlerfall genau?
Reagiert das System gar nicht mehr?
Schlägt der Watchdog zu? Hast Du einen Watchdog?

[kevin m. (kevinm)]

Hab die letzten Tage weiter probiert aber keine Lösung gefunden.

Also beim Fehlerfall wird ein neustart vom Atmega durchgeführt. Einen 
Watchdog habe ich auf 2s eingestellt, dieser wird aber NICHT ausgelöst.

Nach dem Reset startet der Atmega das Programm neu, bleibt aber 
anschließend ungefähr bei der Zeile TFT_HintergrundFarbe(0,0,0); ( also 
ziemlich am anfang ) "hängen". Der Fehler liegt aber nicht an diesem 
Befehl, wenn ich die Zeile entferne hängt der Atmega einfach bei der 
nächsten.

Dann lässt sich der AVR auch mit dem externen Reset nicht mehr starten. 
Es hilft dann nur noch die Spannungsversorgung zu unterbrechen. Das 
gleiche Verhalten hat er übrigens auch, wenn der Watchdog auslöst. Beim 
Watchdog wird zuerst der eingestellte Interrupt ausgelöst und führt 
danach den reset durch. Das Programm startet kurz neu und hängt.

Sehr selten startet der Atmega aber nach dem absturz ganz normal bis zur 
anwendung. Stürzt aber dann sofort ab, wenn ich auf die "Logger App" im 
Touchscreen drücke.

Warum mein AVR beim neustart hängen bleibt und warum er überhaupt 
neustartet bleibt mir noch immer ein Rätsel :/.

[kevin m. (kevinm)]

Ich möcht mich nochmal melden. Bis jetzt noch immer kein erfolg, aber 
auch fast keine motivation mehr für mein Projekt. Vll kann mir jemand 
tips zum debuggen geben? leider stürzt das programm ohne den watchdog 
ab, somit kann ich auch per wd keine registerbits kontrollieren..

[Frank K. (fchk)]

Hast Du einen JTAG-Adapter zum Debuggen? Kannst Du feststellen, ob ein 
Puffer übergelaufen ist? Vielleicht am Anfang und Ende jedes Puffers 
eine Kennung ("magisches" Wort wie 0xCAFFEE00) schreiben und prüfen, ob 
die noch da sind.

fchk

[Juergen G. (jup)]

Ich wuerde das Senden an den PC mit dem USART auch ueber ISR machen und 
nicht in einer while Schleife.

Und reduzier zum Testen mal die Arbeit des uC auf das Notwendigste, also 
nur USART und CAN. Wenn Du dann weiter kommst weisst Du das der uC ins 
schwitzen kommt.

Ju