Bus-off difference between STM32 drivers in libuavcan and libcanard

[James Stewart]

Hi Pavel,

I am attempting to port the Zubax GNSS bootloader to a STM32F446 MCU as you mentioned over here. Everything compiles and runs however when attempting to send a firmware update over the CAN bus it fails every time. The update starts up fine and the bootloader starts sending periodic read requests. However, eventually one of these read requests will fail to send (some of the frames in the request from the bootloader drop according to the uavcan gui tool). As a result, the read request is never fulfilled and the bootloader times out (error -30001). 

My experience thus far with UAVCAN has been entirely with libuavcan and I have never seen frames drop in transmission before. So I set up a test program that uses libuavcan instead of libcanard which just sends a debug message with the value incrementing by 1 every time. I loaded this program onto the same setup and it worked perfectly.

I have tracked this issue down to a difference in the STM32 driver implementation between libuavcan (here) and libcanard (here). libcanard will abort transmissions on an error if the abort_on_error flag is set OR if the bus-off flag is set in the esr register, while libuavcan only checks for the former. Is there a reason for the difference?

I have confirmed this is the reason for the behaviour described above by removing the bus-off check from libcanard and the firmware update works flawlessly. I also added the bus-off check like it is implemented in libcanard to libuavcan and tried my test program and it fail occasionally like libcanard did. 

So my second question is, should I be seeing this many bus errors? Is the bus-off flag being set by hardware indicate there is some other problem or is it normal?

Thanks,

James

[Pavel Kirienko]

Forwarding to the mailing list manually due to a glitch in my email client.

---------- Forwarded message ----------
From: Pavel Kirienko <pavel.k...@gmail.com>
Date: Sat, Oct 7, 2017 at 2:51 PM
Subject: Re: Bus-off difference between STM32 drivers in libuavcan and libcanard
To: James Stewart <james...@gmail.com>

Hi James,

The bus-off state should never be entered on a normally functioning bus. Please describe your hardware setup, perhaps it's faulty.

Pavel

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/fdcef9bd-4f96-4d92-86f4-77fd90c3d84e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Stewart]

I have a Nucleo64 dev board with a STM32F446RE MCU, connected to a SOIC CAN tranceiver on a breadboard with jumper wires. The CAN bus side of the tranceiver is more jumper wires spliced on to a JST GH 4 cable which is plugged into a Babel. The babel is connected to a linux computer running the uavcan gui tool. I have a terminating resistor on the breadboard at the CAN tranceiver and the other is plugged into the Babel.

On Sunday, October 8, 2017 at 1:50:01 AM UTC+11, Pavel Kirienko wrote:

Forwarding to the mailing list manually due to a glitch in my email client.

---------- Forwarded message ----------
From: Pavel Kirienko <pavel.k...@gmail.com>
Date: Sat, Oct 7, 2017 at 2:51 PM
Subject: Re: Bus-off difference between STM32 drivers in libuavcan and libcanard
To: James Stewart <james...@gmail.com>

Hi James,

The bus-off state should never be entered on a normally functioning bus. Please describe your hardware setup, perhaps it's faulty.

Pavel

On Oct 7, 2017 06:28, "James Stewart" <james...@gmail.com> wrote:

Hi Pavel,

I am attempting to port the Zubax GNSS bootloader to a STM32F446 MCU as you mentioned over here. Everything compiles and runs however when attempting to send a firmware update over the CAN bus it fails every time. The update starts up fine and the bootloader starts sending periodic read requests. However, eventually one of these read requests will fail to send (some of the frames in the request from the bootloader drop according to the uavcan gui tool). As a result, the read request is never fulfilled and the bootloader times out (error -30001). 

My experience thus far with UAVCAN has been entirely with libuavcan and I have never seen frames drop in transmission before. So I set up a test program that uses libuavcan instead of libcanard which just sends a debug message with the value incrementing by 1 every time. I loaded this program onto the same setup and it worked perfectly.

I have tracked this issue down to a difference in the STM32 driver implementation between libuavcan (here) and libcanard (here). libcanard will abort transmissions on an error if the abort_on_error flag is set OR if the bus-off flag is set in the esr register, while libuavcan only checks for the former. Is there a reason for the difference?

I have confirmed this is the reason for the behaviour described above by removing the bus-off check from libcanard and the firmware update works flawlessly. I also added the bus-off check like it is implemented in libcanard to libuavcan and tried my test program and it fail occasionally like libcanard did. 

So my second question is, should I be seeing this many bus errors? Is the bus-off flag being set by hardware indicate there is some other problem or is it normal?

Thanks,

James

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+un...@googlegroups.com.

[Pavel Kirienko]

Okay, thanks.

 

Let me answer the question I ignored in my previous response:

 

> I have tracked this issue down to a difference in the STM32 driver implementation between libuavcan (here) and libcanard (here). libcanard will abort transmissions on an error if the abort_on_error flag is set OR if the bus-off flag is set in the esr register, while libuavcan only checks for the former. Is there a reason for the difference?

 

The behavior of the buffers in the bus-off state is poorly specified. Some implementations discard all data in the buffers once the bus-off state is entered, others don't. It just so happened that libuavcan retains the contents of its buffers through the bus-off state, whereas libcanard, being a bit simpler on the driver layer, drops the frames that could cause the bus-off condition. Both approaches can be considered technically correct.

 

The fact that libuavcan works for you whereas libcanard fails does not mean that libcanard is at fault. It merely means that libuavcan tries to do the best it can, given a faulty bus, which hides the problem from the eyes of the developer, whereas libcanard fails earlier.

 

You should revise your wiring and physical layer in general. Try lower bitrates and see if the problem still persists. If it goes away at 125 kbit/sec, your problem is definitely caused by some issues with the physical layer.

 

-- 

Pavel Kirienko

CVO/CTO, co-founder

Zubax Robotics

 

 

 

08.10.2017, 02:41, "James Stewart" <james...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/d2015878-463f-4897-b616-daea794a1b0e%40googlegroups.com.