CAN STM32F7xx

[hawky (Gast)]

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?

   while (1)
    {
        //HAL_Delay(500);
        if( ( millis()-lastMillis1 ) > 50){

        //char strLabel4[25];
        //itoa(RxHeader.StdId, strLabel4,10);
        //HAL_UART_Transmit(&huart3,strLabel4,10,1);

        TxData[0] = 0x44;
        HAL_CAN_AddTxMessage(&hcan2, &TxHeader, TxData, &TxMailbox);


        //HAL_UART_Transmit(&huart3,RxHeader.StdId,sizeof(RxHeader.StdId),1);


      //HAL_UART_Transmit(&huart3,"Loop",5,1);
            lastMillis1 = millis();
        }

        if( ( millis()-lastMillis3 ) > 1){


            HAL_CAN_GetRxMessage(&hcan2, CAN_RX_FIFO0, &RxHeader, RxData);
        if(RxHeader.StdId == 0x021 ){
          HAL_GPIO_TogglePin(GPIOI, GPIO_PIN_8); //LED 101

          uint32_t value = (RxData[7]<<24) | (RxData[6]<<16) | (RxData[5]<<8) | RxData[4];

            char strLabel5[25];
            itoa(value, strLabel5,10);
          HAL_UART_Transmit(&huart3,strLabel5,5,1);
          value = value / 1000;

        }else if(RxHeader.StdId == 0x021){

        }

          lastMillis3 = millis();
        }

    }
}

[uff basse (Gast)]

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.

[Bastian W. (jackfrost)]

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

[Thomas F. (igel)]

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.

[hawky (Gast)]

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):

    /* Check that all the Tx mailboxes are not full */
    if (((hcan->Instance->TSR & CAN_TSR_TME0) != RESET) ||
        ((hcan->Instance->TSR & CAN_TSR_TME1) != RESET) ||
        ((hcan->Instance->TSR & CAN_TSR_TME2) != RESET))
    {

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....

[hawky (Gast)]

> 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....

[hawky (Gast)]

also, bei deaktivierten externen GPIO Interrupt (für Touch) funktioniert 
der CAN stabil....

wo suche ich hier am besten nach dem Fehler?

[hawky (Gast)]

Im folgenden Link scheint jemand ein ähnlichen Fehler zu haben:

https://electronics.stackexchange.com/questions/212194/stm32f7-gets-stuck-in-external-interrupt-callback-function

HAL_InitTick(0); im Init-Teil hilft bei mir aber nicht...

[hawky (Gast)]

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)...