CAN Bus strange signal (solved)

[Tom Schrauf]

edit: the problem was due to a CAN-master switching baudrates on the fly.

the wrong (slower) timing was detected by the CAN controller causing the interruption of the ongoing transmission.

Hello Community !

I am implementing CAN communication with an inverter and sometimes experience communication failures. The inverter is the only one sharing the bus.

The interface is setup @500kBaud, STM32F407 (revision 2) 100pins, CAN1 (A11,A12) and works fine except getting this strange behavior sometimes, which I can't understand.

I use interrupt driven Receive and cmsis CanTransmit fct.

SCE ISR just clears errors:

   CAN1->ESR = (uint32_t)RESET;

   CAN1->MSR = CAN_MSR_ERRI;

From that point on the inverter transmits corrupted frames for about 10s until it sort of recovers.

My CAN-Init:

   CAN_InitStructure.CAN_TTCM = DISABLE;

   CAN_InitStructure.CAN_ABOM = DISABLE;

   CAN_InitStructure.CAN_AWUM = DISABLE;

   CAN_InitStructure.CAN_NART = ENABLE;

   CAN_InitStructure.CAN_RFLM = ENABLE;

   CAN_InitStructure.CAN_TXFP = ENABLE;

   CAN_InitStructure.CAN_Mode = CAN_Mode_Normal;

   CAN_InitStructure.CAN_SJW = CAN_SJW_1tq;

I am a bit new to CAN-Bus so the solution might be very trivial.

I do not understand why the TX-Line is being activated interfering the ongoing transmission with a well shaped pattern.

What did I do wrong and how can the CAN TX line be activated without sending or receiving ? Is this part of the BUS arbitration and what is the condition that forces the CAN controller to behave like that (all queues empty).

Thank you for reading all this !

Tom

[SofLit]

Dear @Tom Schrauf​ ,

I suggest as a first step to check your HW:

- If you are using HSI as clock for CAN communication, this is not recommended. Please use an external crystal.

- Usage of transceivers. Many people deal with CAN interface as UART or SPI etc. Transceivers should be used in CAN normal mode.

- Usage of twisted pair wiring.

- Usage of termination resistors of 120ohms x 2.

Check also if you have micro discontinuity in your wiring.

[Javier1]

I think That Tx blimp you see is the canbus peripheral ACKing the received message.

Or it could be noise, anyway, using the analog readings (osilloscope) will give you a lot more info about what is going on.

[Tom Schrauf]

Thank you for your answer.

The board I am using has an external crystal and the transceiver is a TJA1050 with 120 Ohms termination on both sides and a 15 Meter shielded twisted pair cable in between. CAN timing should be at 80%.

   /* CAN clocked at 42MHz */

   // see RM0090 note

   // 336 clk = CAN_Prescaler * (1 + CAN_BS1 + CAN_BS2)

   // PCLK = 42MHz

   // http://www.bittiming.can-wiki.info/

   switch( speed ) {

...  

 case CAN_BAUDRATE_500K:

      CAN_InitStructure.CAN_Prescaler = 6;

      CAN_InitStructure.CAN_BS1 = CAN_BS1_11tq;

      CAN_InitStructure.CAN_BS2 = CAN_BS2_2tq;

      break;

....

My problem is that the communication is working very well until the situation above is occurring, So there are hundreds of frames received and sent without ANY error. But out of a sudden the CAN controller interrupts a frame being sent by the other party.

I have deactivated all other parts of the software (background DMA ADC-reading, background USART and SPI tasks) not to interfere in any way so the CAN communication is the only task running besides SysTic and TIM5 scheduling the transmits.

If i used silent mode the other side would sent different frames so I think the scenario would not be happening but IMO the CAN controller inside the STM32 is a bit confused and it has got nothing to do with HW issues. There is a 500mS period of recessive state so the frame start should be easily detectable but the controller interferes already at the very beginning *rollingeyes*

Thanks, Tom

 Communication before and after the strange behavior pretty normal and stable....

[Tom Schrauf]

Hello Javier,

These boinks would be very misaligned and way too fast if you consider the first 8 of them.

Seems the CAN controller lost sync and the retransmitted frames (in the above example) are maybe ACKED but the according frames not received.

After six boinks the STM32 seems to recognize the problem (it caused by itself) and raises frame warning/error interrupt (see the circle).

But it is unfortunately not able to resync the bitstream. Only when the sender stops successive retransmission communication continues and stays stable for hours then.

This is the picture of regular frames and the point when things screw up.

[SofLit]

"it has got nothing to do with HW issues." --> not yet sure .. CAN communication is sensitive and sending/receiving hundreds of frames with some errors doesn't mean you don't have HW issues: wiring, EMC issues etc ..

Do you have the possibility to decrease the wiring length? and/or may be to decrease the bitrate?

Do you have the possibility to debug the inverter communication with a CAN tool as a replacement of STM32?

PS: the CAN controller inside STM32 passed the ISO CAN conformance test: link. 

[Tom Schrauf]

Well the wiring length and baudrate are given (the inverter is installed in the cellar and communicates at a fixed 500kBits).

I do not have any other debugging tool than the DSView logic analyzer.

Should i maybe use CAN2 to see if the problem persists ?

Well maybe the problem is that the inverter is not a road vehicle ;)

[Javier1]

Im so glad we stablished boinks as a technical term.

>>After six boinks the STM32 seems to recognize the problem (it caused by itself) and raises frame warning/error interrupt (see the circle).

Are you using cubeMX? show me the canbus config.

Im thinking is not able to transmit anything and some fifo is filling up somehwere returning you errors.

I still advise you to capture the signals using an oscilloscope, try to capture a boinks

[SofLit]

I don't think the usage of CAN2 will change something as it has the same implementation of CAN1.. but ok, you can test it ..

PS: don't forget to enable CAN1 clock if you are using CAN2, otherwise it will not work ;-).

[SofLit]

@Javier Muñoz​ ,

From the picture of his first post, a Form Error interrupt is raised. So the issue comes from the frame structure itself.. That's why I'm suspecting a hardware issue.