Hallo,
ich verzweifle gerade daran eine CAN Schnittstelle mit dem STM32F746
stabil in Betrieb zu nehmen. Ich verwende den externen Clock (25MHz).
Die CAN Schnittstelle empfängt immer richtig, aber plötzlich nach 1min
oder 10 Sek oder auch erst nach 10min oder länger, wird immer nur noch
der gleiche Wert empfangen + es scheint dass dann auch nichts mehr
gescheites herausgesendet wird (also Tx geht dann auch nicht mehr).
Im Debug-Modus tritt der Fehler irgendwie gar nie auf.... :-(
Mein Code sieht in etwa so aus (Rx Interrupt deaktiviert):
Sehr ihr ein groben Fehler in diesem Code?
hawky schrieb:> Sehr ihr ein groben Fehler in diesem Code?
Ja. Man kann ihn nicht lesen. Ich habe keine Lust so einen
hingeworfenen schlecht eingerückten Code neu zu formatieren.
Man kann so etwas auch als *.c Datei als Anhang mitliefern.
Oft findet sich der Fehler auch in Bereichen die nicht gezeigt
werden.
Und magic Numbers im Code werden so manchen Leser daran hindern
sich mit deinem Code auseinanderzusetzen. Mich auch.
Deine Hardware ist ausser Zweifel! Du weisst es genau, sonst
würdest du etwas darüber aussagen bzw. zeigen. An der Hardware
kann es ja nie liegen.
Können die anderen CAN Nachrichten in den 50 ms verarbeiten in den denen
die rausgeschickt werden ?
Hast du mal auf den Bus geschaut ob da immer ein Ack kommt ?
Gruß JackFrost
hawky schrieb:> es scheint dass dann auch nichts mehr> gescheites herausgesendet wird (also Tx geht dann auch nicht mehr).
Bei Fehlern mit CAN-Bus empfiehlt es sich die Register REC und TEC in
denen sich die CAN-Error-Counter befinden regelmäßig auszulesen und zu
beobachten: Bei 128 Fehlereinträgen wird CAN deaktiviert.
Sorry wegen der Formatierung...
Thomas F. schrieb:> Bei Fehlern mit CAN-Bus empfiehlt es sich die Register REC und TEC in> denen sich die CAN-Error-Counter befinden regelmäßig auszulesen und zu> beobachten: Bei 128 Fehlereinträgen wird CAN deaktiviert.Bastian W. schrieb:> Hast du mal auf den Bus geschaut ob da immer ein Ack kommt ?
Alles möglich, nur habe ich keine Ahnung wie ich all dies überprüfen
soll. Scheint, dass man die HAL-CAN Funktionen (AddTx und GetTx) nicht
einfach so im Loop verwenden kann ohne noch andere Bits oder Flags zu
überprüfen... Schade :-( ...
Ich habe noch einen externen Interrupt GPIO Eingang (für das
Touch-Display). Wenn dieser mehrmals kommt, dann hängt sich der CAN auch
auf.
Ich habe das RX CAN Interrupt nicht aktiviert...
Aber ja, scheint trotzdem irgendwo ein verflixter Konflikt mit
Interrupt, DMA oder weiss der Geier was... komplex. Muss wohl wieder
zurück auf UART :-(
Beim TX scheint dann die Mailbox immer voll (gemäss Debugger):
1
/* Check that all the Tx mailboxes are not full */
2
if(((hcan->Instance->TSR&CAN_TSR_TME0)!=RESET)||
3
((hcan->Instance->TSR&CAN_TSR_TME1)!=RESET)||
4
((hcan->Instance->TSR&CAN_TSR_TME2)!=RESET))
5
{
Und beim RX gibt es kein Error, aber er liest dann immer dieselbe
SdtId....(obwohl andere ID's gesendet werden)
Und wie gesagt, ohne berühren des Touches funktioniert Senden und
Empfangen immer eine Weile gut....
> Und wie gesagt, ohne berühren des Touches funktioniert Senden und> Empfangen immer eine Weile gut....
ich prüfe noch wie lange es funktioniert wenn ich den Touch-Interrupt
deaktiviere....
also es hängt nicht mal mit dem externen Interrupt zusammen, der CAN
hängt sich auf wenn ich nur schon ein Lesebefehl an diesem GPIO-Eingang
mache (GPIO 13, Port I)...