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

[mƎALLEm]

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]

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.

[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

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

[mƎALLEm]

"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 ;)

[Tom Schrauf]

AND THANK YOU ALL FOR HELPING EVEN ON CHRISTMAS DAY.

NO MATTER I CAN SOLVE THE PROBLEM OR NOT I WISH YOU ALL A MERRY CHRISTMAS !!!!

[Tom Schrauf]

I think I maybe found the reason.

At 500kBaud the CAN startbit is supposed to last 10uS but the inverter, i am communicating with, seems to change baudrate and begins with a 12uS startbit.

This is of course disliked by the STM32 and all consecutive frames are ignored (not showing a proper startbit) (frame duration > 400uSecs so definitely not 500kBaud).

What I am still wondering is why 8 pulses are generated and why the Error interrupt is not immediately activated (and why it is only activated once).

I will try to find out to which framerate the inverter switches to (and then back to 500kBaud after 15seconds) by toggling the frame-rate on the fly within the SCE ISR just for curiosity.

Have a nice Christmas !

Tom

So the blackbox really changes the baudrate from 500 to 250kBaud - Sorry that I have bothered you but I did not expect my first CAN communication to act like this.

I now lower the baudrate with a complete reinit (only setting BTR on the fly did not work) from within the SCE ISR and the second frame is than received at the lower rate. Maybe the blackbox did not really like my replies making it try different communication protocol/speed.

Attached see the error and switch to 250kBaud - not funny for a first CAN expertise :D

 

Thank you once more guys !

[mƎALLEm]

I didn't understand this point: "At 500kBaud the CAN startbit is supposed to last 10uS but the inverter, i am communicating with, seems to change baudrate and begins with a 12uS startbit."

--> At 500kBaud the CAN startbit is supposed to be 2us and not 10us. Start bit should have the same duration as the subsequent bits in the frame otherwise the node is not following the spec. 12uS corresponds to the bitrate of 83,333kb/s. Please check this point.

Also as I understood, your inverter is switching the CAN bitrate on the fly, and has a "strange" start bit duration which is not inline with the current frame rate! I could not expect a CAN node to switch its bitrate on the fly and disturbs the communication! 

So what I can suggest is to use Silent mode from STM32 side in order to detect the inverter bitrate and then switch to the normal mode when the bitrate value is established.

[Tom Schrauf]

Well the term "startbit" was not correct. the measured times of 10 and 12uS included both the SOF and the beginning of the arbitration field i guess. For that reason the dominate time at the beginning is longer than 2 or 4 uS as can be seen on the diagrams. After ~12uS the STM CAN controller recognized timing was too slow and interrupted the frame transmission 8 times raising the error (only once?!).

The inverter definitely starts with a sequence of extended frames and sends them every 250mS for about 10 seconds.

Then after a pause of 500mS it switches the baudrate on the fly from 500kBaud to 250kBaud (which is when the errors above occurred) and tries to communicate (i.E. sends several different well formed frames every 250mS) at the lower baudrate.

After 15seconds of doing so it again pauses for 500mS and switches back to the 500kBaud and communication proceeds at this baudrate.

So the inverter checks for the communication party (usually only one device is attached), whether it communicates/(is able to) on 250kBaud or not. The frames at the lower baudrate use different identifiers so a different "dialect" is used at that speed.

I now adopted to this behavior waiting for the delay to exceed 350mS, switching down the baudrate - receive and discard the frames received @250kBaud - and switch back to 500kBaud again. Works like that although it is not really required and does not save time but at least having no communication errors and knowing the blackbox a little better :D

I did not expect the inverter to switch baudrates "on the fly" either - otherwise I would not have bothered you to help.

Thank you for all your advice.

Have a great 2022 !

Tom