2021-12-23 06:01 AM
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
2021-12-24 07:32 AM
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 !
2021-12-28 02:34 AM
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.
2021-12-29 02:53 PM
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