Vad är felet om CAN-bus slutar fungera efter ett tag?

[DanielM]

Jag har två 100% identiska enheter med CAN-bus. Samma mjukvara osv. Vi kallar dom för ECU A och ECU B.

När jag kör ECU A helt öppet så kan jag mäta med mitt oscilloskop att ECU A skickar ut CAN-signaler.
När jag kopplar ihop ECU A med ECU B så går det ca 40-50 signalpaket, sedan så kan min ECU A inte skicka något mera enligt oscilloskopet. Då får jag detta meddelande.

Skärmbild 2022-11-29 203015.png

Om jag kopplar bort ECU B från CAN-nätverket, så har ECU A fortfarande samma problem. Så ECU A måste startas om för att fungera igen.

Då är min frågeställning.
Om två enheter ej kan prata med varandra via CAN-bus efter X antal CAN-meddelanden. Vad brukar felet vara då? Kan det vara en buffer som har fyllts upp helt?

[Klas-Kenny]

Är bussen felfri fram tills det plötsligt bara stannar?

Annars är det inte helt ovanligt att en CAN-controller stänger av sig vid för många fel på bussen, så att man aktivt måste initiera controllern igen.

[DanielM]

Jag har lite problem med meddelanden faktiskt. Ibland måste jag skicka två meddelanden innan något av dom kommer fram.
Båda dom där två ECU enheterna, vilket är STM32, uppvisar samma problem.

Om jag bara kör ECU B och inte kopplar på ECU A på nätverket. Då fungerar ECU B jätte bra. Men kopplar jag på ECU A på nätverket, då kommer ECU B tillslut att sluta skicka CAN-meddelanden efter X antal meddelanden.

Nu har jag hittat problemet. Det är: HAL_CAN_ERROR_PARAM = 0x200000

Så det är fel på mina parametrar. Skumt, det var det inte förr. Jag har inte ändrat inställningarna något.
Eller har ni något som ni skulle vilja tillägga? Jag har på 250 kB/s som baudrate. Det är en vanlig hastighet.

Skärmbild 2022-11-29 203015.png

Här är orsaken. Mina TX mailboxes är fulla. Jag har ingen aning hur jag tömmer dom.

Kod: Markera allt

/* Check that all the Tx mailboxes are not full */
    if (((tsr & CAN_TSR_TME0) != 0U) ||
        ((tsr & CAN_TSR_TME1) != 0U) ||
        ((tsr & CAN_TSR_TME2) != 0U))
    {
      /* Select an empty transmit mailbox */
      transmitmailbox = (tsr & CAN_TSR_CODE) >> CAN_TSR_CODE_Pos;

      /* Check transmit mailbox value */
      if (transmitmailbox > 2U)
      {
        /* Update error code */
        hcan->ErrorCode |= HAL_CAN_ERROR_INTERNAL;

        return HAL_ERROR;
      }

      /* Store the Tx mailbox */
      *pTxMailbox = (uint32_t)1 << transmitmailbox;

      /* Set up the Id */
      if (pHeader->IDE == CAN_ID_STD)
      {
        hcan->Instance->sTxMailBox[transmitmailbox].TIR = ((pHeader->StdId << CAN_TI0R_STID_Pos) |
                                                           pHeader->RTR);
      }
      else
      {
        hcan->Instance->sTxMailBox[transmitmailbox].TIR = ((pHeader->ExtId << CAN_TI0R_EXID_Pos) |
                                                           pHeader->IDE |
                                                           pHeader->RTR);
      }

      /* Set up the DLC */
      hcan->Instance->sTxMailBox[transmitmailbox].TDTR = (pHeader->DLC);

      /* Set up the Transmit Global Time mode */
      if (pHeader->TransmitGlobalTime == ENABLE)
      {
        SET_BIT(hcan->Instance->sTxMailBox[transmitmailbox].TDTR, CAN_TDT0R_TGT);
      }

      /* Set up the data field */
      WRITE_REG(hcan->Instance->sTxMailBox[transmitmailbox].TDHR,
                ((uint32_t)aData[7] << CAN_TDH0R_DATA7_Pos) |
                ((uint32_t)aData[6] << CAN_TDH0R_DATA6_Pos) |
                ((uint32_t)aData[5] << CAN_TDH0R_DATA5_Pos) |
                ((uint32_t)aData[4] << CAN_TDH0R_DATA4_Pos));
      WRITE_REG(hcan->Instance->sTxMailBox[transmitmailbox].TDLR,
                ((uint32_t)aData[3] << CAN_TDL0R_DATA3_Pos) |
                ((uint32_t)aData[2] << CAN_TDL0R_DATA2_Pos) |
                ((uint32_t)aData[1] << CAN_TDL0R_DATA1_Pos) |
                ((uint32_t)aData[0] << CAN_TDL0R_DATA0_Pos));

      /* Request transmission */
      SET_BIT(hcan->Instance->sTxMailBox[transmitmailbox].TIR, CAN_TI0R_TXRQ);

      /* Return function status */
      return HAL_OK;
    }
    else
    {
      /* Update error code */
      hcan->ErrorCode |= HAL_CAN_ERROR_PARAM; <<<----- Här hamnar jag

      return HAL_ERROR;
    }

[gustavn]

Har du termineringsmotstånd?

[DanielM]

60.9 ohm - kondensator - 60.9 ohm.

Alltså 120 typ i praktiken. Det är riktigt skumt att det ska bli så här. Jag uppdaterade min firmware på min STM32:a och sedan dess blev det så här. Men jag har även varit på kretskortet och rengjort riktigt och rejält. Men det känns snarare som ett mjukvaruproblem, än hårdvaruproblem då min STM32:a klagar på att jag har satt fel parametrar.

[Klas-Kenny]

Börja med att testa med normal terminering, 120 ohm i varje ände på bussen.

[DanielM]

Jag vet att detta är känsligt. Men jag följde bara rekommendationen från databladet.

Jag har normalt kunnat prata med andra enheter som har 120 ohm i termineringsmotstånd. Då har det fungerat. Men nu har jag två exakta enheter som har 60 - kondensator - 60 som termineringsmotstånd. Det fungerar inte riktigt. Jag misstänker också att det kan vara detta.

TCAN33x 3.3-volt har jag för CAN-modul...typ. Mina misstankar är att på grund utav detta 60.9 ohm - kondensator - 60.9 ohm så fungerar inte termineringsmotståndet riktigt, till skillnad 120 ohms motstånd. Jag misstänker att det kan vara så, för att om inte ett CAN-meddelande kan sändas ut, så kommer inget ACK, och därmed så slutförs inte meddelandet.

Skärmbild 2022-11-29 203015.png

https://www.ti.com/lit/ds/symlink/tcan3 ... e.com%252F

[DanielM]

Om termineringsmotstånderna är 10 cm ifrån varandra. Detta kanske orsakar ett problem?
Alltså ECU A och ECU B är 10 cm ifrån varandra.

[gustavn]

För korta busslängder brukar det funka bra med bara ett motstånd är min erfarenhet

[DanielM]

Jag har lite längre kabel nu. Ca 1.3 meter. Det är samma visa här också. Om jag har ECU A och ECU B inkopplade med varandra. Jag mäter resistansen på CANH och CANL så får jag 61 ohm.

Det är alltså 60.9 - kondensator - 60.9 som termineringsmotstånd. Två stycken sådana motstånd parallelt och resistansen halveras. Så resistansen verkar OK.

Edit 1:
Jag testade även ta bort ett termineringsmotstånd. Nu fungerar inte kommunikationen alls. Så termineringsmotstånd måste jag ha i båda endar.

Edit 2:
Jag kopplade tillbaka det.

Men något som jag märker är att hela meddelandet verkar inte komma helt fram.
Jag måste typ skicka flera meddelanden, innan mottagaren får meddelanden.

Jag har LED-lampor på mina ECU enheter. När någon får ett meddelande eller skickar ett meddelande, så blinkar en LED-lampa.

Edit 3:


Uteslutningsvis så är det mina Tx mailboxes som är fulla.

You only have three transmit mailboxes. That means that you can set only three frames pending for transmit by the bxCAN controller. Others have to wait in software buffers.

If you did not implement the error handlers of CAN bus and cancel transmission when they fail (eg: bus full, no acknowledge or arbitation failure) you will eventually use up all mailboxes.
The hardware does not provide a timeout function, you have to keep track of possible mailbox timeouts yourself.

Your code only aborts transmit of box 0 when all mailboxes are full, so your behavior is not strange.

Also, if you did enabled the automatic retransmit feature, mailboxes will never free automatically until transmit is successfully completed.

https://stackoverflow.com/questions/598 ... controller

Detta låter mycket troligt med tanke på att jag får HAL_CAN_ERROR_PARAM som felkod.

Kod: Markera allt

uint32_t tsr = READ_REG(hcan->Instance->TSR); /*!< CAN transmit status register,        Address offset: 0x08          */
/* Check that all the Tx mailboxes are not full */
    if (((tsr & CAN_TSR_TME0) != 0U) ||
        ((tsr & CAN_TSR_TME1) != 0U) ||
        ((tsr & CAN_TSR_TME2) != 0U))
    {
    /* Massa kod.... */
    }else{
     /* Update error code */
      hcan->ErrorCode |= HAL_CAN_ERROR_PARAM;

      return HAL_ERROR;
    }

Skärmbild 2022-11-29 203015.png

Här kan vi verifiera att mina Tx mailboxar är fulla. Orsakerna kan vara:

• Jag skickar för snabba meddelanden.
• Inget ACK skickas (med tanke på att jag får skicka minst 2 meddelanden, innan den uppfattar ett meddelande)
• För låg spänningsnivå (Jag kör ju precis 3.3V så det ska nog inte vara ett problem. Men vem vet...)

Edit 4:
Med tanke på att jag får tsr = 0b10000010000000000000000000000000 = 0x82000000 så betyder det att det är något med min mailbox.
Hur som helst så är ingen av dessa mailbox tomma, vilket är problemet!

Skärmbild 2022-11-29 203015.png

Edit 5:
Nu använder jag denna inställning. Nu kan jag inte alls tala med någon annan ECU enhet. Dessutom om jag bara kör ECU A helt öppet utan att koppla in mig på nätverket, så får jag samma felmeddelande.

Skärmbild 2022-11-29 203015.png

Edit 6:
När jag har min första inställning så fungerar det att köra en ensam ECU enhet.
Då får jag

Kod: Markera allt

tsr  = 0b11100000000000000001100000011

Vilket indikerar att meddelandet är OK.

Så hur kommer det då sig att om jag har två stycken EXAKT likadana ECU enheter, med exakt samma mjukvara och hårdvara, får problem att tala med varandra? Och allt verkar ligga i inställningarna.

Edit 7:

Lite framsteg nu. Nu kan jag skicka data, utan att min CAN-modul får något fel. Men min mottagare svarar inte på meddelandet.
Det jag har gjort är att jag har ställt in tiderna för min CAN-modul.
http://www.bittiming.can-wiki.info/#bxCAN

Kod: Markera allt

tsr = 0b11100000000000000001100000011

Skärmbild 2022-11-29 203015.png

Skärmbild 2022-11-29 203015.png

[Mindmapper]

Mycket svammel om termineringsmotstånd.
Bilderna visar en sak sedan svamlar du om parallellkoppling och halvering. Det blir det dvs. 30.5 ohm. Men det ska vara 120 ohm.

Sedan plockar du bort ett motstånd. Om du plockar bort ett 60.9 ohms motstånd vad uppnår du för balansering då?

Det enklaste testet du kan göra är att ta bort kondensatorn som sitter mellan de två motstånden.
Väldigt enkelt att prova, tror ej att det påverkar men det är så enkelt att göra att det vore dumt att inte prova.

[DanielM]

Jag har fått det fungera nu.
Det var Seg 1, Seg 2 och perscaler som skulle ställas in korrekt
Plus så skulle canbis ha ett canfilter.