ErrorStatus() always CAN_ERROR_PASSIVE

[nlwelch]

We've noticed an odd condition when our application starts and enables CAN and there is another device on the bus whose baud rate is different. We log the error passive condition and our app then attempts to transmit data (every second). We do this as the Particle documentation states that the error state will only be corrected after an attempt to transmit. If we correct the baud rate (in this case it's just Kvaser and we set the baud rate to match), the error status continues to report CAN_ERROR_PASSIVE, even though the application successfully transmits CAN messages.

We are currently coding for this condition and resetting our CAN channel. Resetting simply consists of:
1. disableCAN() { executing a can.end(), then turn off the CAN enable pin }

1. enableCAN() { turn on the CAN enable pin, execute can.begin(baudRate) }

Any ideas on why this is happening?

[nlwelch]

Worth noting: This only happens when the application starts and there is an incompatible baud rate. Meaning, if we start and the devices are compatible (both at 500 kbits/s), and we then change the baud rates, everything works as expected. We observe the error passive condition. After a short period of time we set the baud rate back to be compatible and the device transitions from error passive to can no error.

[cyclin_al1]

@nlwelch,

I am not sure what is going on at the moment. It sounds like something in the underlying STM3F CAN support or in the Particle DeviceOS. For starters, can you indicate which Particle device you are using and what version of DeviceOS you are running?

@jvanier, any thoughts on this?

[nlwelch]

We're using an Electron and Device OS 0.6.4

[alanm]

then change the baud rates, everything works as expected. We observe the error passive condition. After a short period of time we set the baud rate back to be compatible and the device transitions from error passive to can no error.

@nlwelch does this happen with Firmware Version 1.0.1?

[jvanier]

What is unexpected in the behavior you describe? Error passive sounds ok in case of a baud rate mismatch.

For details about the state machine of the CAN error handling, you need to dig in the STM manual. https://www.st.com/resource/en/reference_manual/cd00225773.pdf

[nlwelch]

Maybe I wasn't clear. As long as the application starts without a mismatched baud rate everything works as expected. Now, if the application starts and there is a mismatched baud rate, the CAN bus always reports CAN_ERROR_PASSIVE, even after the baud rate is corrected on the other device. Just as interesting is that while in this state the application successfully transmits even though it's reporting a status of CAN_ERROR_PASSIVE.

We're building an application and reading it for production. We're putting it through the real world conditions we expect it to experience. Our test fixtures consist of an Electron with Carloop, a Kvaser cable connected to a PC (allows for simulating various conditions), and CAN termination.

Hope this clears up the confusion.

[nlwelch]

I will try 1.0.1 today. Are there any issues using Carloop and Carloop GPS with 1.0.1?

[cyclin_al1]

@nlwelch,

I would suggest going ahead and try some testing with 1.0.1.
As far as I know, the CAN functionality in DeviceOS has not changed since it was developed by a Particle Community member a few years ago. Of course, something else could have had an indirect effect on the CAN functionality.
I am not aware of any issues.