# CAN3 with STM32 trouble

**URL:** <https://forum.opencyphal.org/t/can3-with-stm32-trouble/440>\
**Category:** Applications & Usage\
**Created:** [April 12, 2019, 12:11pm UTC](https://forum.opencyphal.org/t/can3-with-stm32-trouble/440 "2019-04-12T12:11:26Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sergey\_Frolov](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/s/b19c9b/32.png) [@Sergey\_Frolov](https://forum.opencyphal.org/u/Sergey_Frolov)\
**Post date:** [April 12, 2019, 12:11pm UTC](https://forum.opencyphal.org/t/can3-with-stm32-trouble/440/1 "2019-04-12T12:11:26Z")

</div>

Hello. I have some trouble with using libuavcan on STM32.  
As I see, the value UAVCAN\_STM32\_NUM\_IFACES defines literally number of current CAN periph in STM32 (CAN1, CAN2…). If I want use CAN1, I must define UAVCAN\_STM32\_NUM\_IFACES as “1”, if CAN2 - as “2”.  
Right?  
But some STM32 controllers has CAN3 also. And … hence I must define \_NUM\_IFACES as “3”…  
But… I see, that UAVCAN\_STM32\_NUM\_IFACES cannot contain value more than 2.  
What can I do for turning on CAN3 using libuavcan? One way I see - redefine values, used for other two CANs?

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [April 12, 2019, 9:51pm UTC](https://forum.opencyphal.org/t/can3-with-stm32-trouble/440/2 "2019-04-12T21:51:45Z")

</div>

Hi Sergey. The macro `UAVCAN_STM32_NUM_IFACES` contains the number of CAN interfaces that will be used by the library, and there are two valid values:

- 1 - only CAN1 will be used
- 2 - both CAN1 and CAN2 will be used (dual modular redundancy)

The third CAN interface is not supported irrespective of the platform.

---

<div class="post-metadata">

**Author:** ![Sergey\_Frolov](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/s/b19c9b/32.png) [@Sergey\_Frolov](https://forum.opencyphal.org/u/Sergey_Frolov)\
**Post date:** [April 14, 2019, 6:59am UTC](https://forum.opencyphal.org/t/can3-with-stm32-trouble/440/3 "2019-04-14T06:59:51Z")

</div>

Thanks, Pavel.  
I understood that CAN3 is unsupported.  
Well.. Just our PCB designer made a mistake, and spent CAN3 wire instead CAN1. And now …  
Is it any way to redefine CAN1 to CAN3 with minimal manual operations??

And I see a good idea to have opportunity to switch on/off each CAN in libuavcan separetely from each other (only CAN1, CAN2, CAN3.. or both CAN1+CAN2 or CAN2+CAN3+CAN100(fantastic as example))

Also PX4 source code (FMU-v5) initialize all three CANs. It seems, that CAN3 is fail and unused in it. I asked the similar question in PX4 community.

> **[FMU-v5 and libuavcan CAN buses quantity are different](https://discuss.px4.io/t/fmu-v5-and-libuavcan-can-buses-quantity-are-different/10456)**
>
> Hello. I really confused with quantity of available CAN buses in FMU-v5. I clearly see, that FMU-v5 source code defines all 3 CANs at STM32F7. #define GPIO\_CAN1\_RX GPIO\_CAN1\_RX\_5 /\* PI9 \*/ #define GPIO\_CAN1\_TX GPIO\_CAN1\_TX\_4...

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [April 14, 2019, 2:01pm UTC](https://forum.opencyphal.org/t/can3-with-stm32-trouble/440/4 "2019-04-14T14:01:34Z")

</div>

> [@Sergey\_Frolov](#):
>
> Is it any way to redefine CAN1 to CAN3 with minimal manual operations??

Yes, you will need a soldering iron and a piece of wire.

> [@Sergey\_Frolov](#):
>
> And I see a good idea to have opportunity to switch on/off each CAN in libuavcan separetely from each other (only CAN1, CAN2, CAN3… or both CAN1+CAN2 or CAN2+CAN3+CAN100(fantastic as example))

I don’t think it’s going to be useful in the upstream. The stock STM32 driver should be considered an implementation example which you can base your own custom driver on. If you need CAN3, just take the stock driver and modify it as necessary. Supporting every possible combination of CAN peripherals would likely add too much variance into the build process, complicate testing and hurt the general robustness of the driver (which is already pretty bad considering that we support so many different RTOSes and peripheral configurations).

You should also keep in mind that you can’t use CAN2/CAN3 without enabling CAN1 (more info in the reference manual).

---

<div class="post-metadata">

**Author:** ![Sergey\_Frolov](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/s/b19c9b/32.png) [@Sergey\_Frolov](https://forum.opencyphal.org/u/Sergey_Frolov)\
**Post date:** [April 22, 2019, 11:55am UTC](https://forum.opencyphal.org/t/can3-with-stm32-trouble/440/5 "2019-04-22T11:55:06Z")

</div>

Unfortunately, BGA package assumes to show any masterclass of manual wiring. I redefined any constants in libuavcan to CAN3 instead CAN1. It works well.  
I dont see any reasons not to add CAN3 to library. Take note to this offer.  
Thanks.

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [May 3, 2019, 4:39pm UTC](https://forum.opencyphal.org/t/can3-with-stm32-trouble/440/6 "2019-05-03T16:39:35Z")

</div>

> [@Sergey\_Frolov](#):
>
> I dont see any reasons not to add CAN3 to library. Take note to this offer.

Supporting CAN3 is certainly a good thing. What I am against of is providing additional configuration options for the library allowing the user to use CAN3 or CAN2 instead of CAN1. There should be three regular options:

- 1 – CAN1
- 2 – CAN1 and CAN2
- 3 – CAN1, CAN2, and CAN3

---

<div class="post-metadata">

**Author:** ![Sergey\_Frolov](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/s/b19c9b/32.png) [@Sergey\_Frolov](https://forum.opencyphal.org/u/Sergey_Frolov)\
**Post date:** [May 5, 2019, 3:10am UTC](https://forum.opencyphal.org/t/can3-with-stm32-trouble/440/7 "2019-05-05T03:10:42Z")

</div>

Hello, Pavel.  
I also agree with your options, described above.  
In my situation I redefined CAN1 as CAN3 as it was more light way for testing failed-wired PCB, until we got corrected plate (with CAN1 wired). It was a temporary solution. But in perspective it should be fine to have CAN3 in libuavcan  
Thanks.
