h7 CAN not available

Hello everyone,

I am currently in the process of switching from the M7 to the H7. However it seems there
is no CAN module builtin to the H7 firmware. CAN however is crucial for my current project.

from pyb import CAN
→ ImportError: cannot import name CAN

Note that this works flawlessly on the M7

Also help(pyb) shows no can module whatsoever.
I tested the same with both v3.41 as well as v3.2 but no difference.
Looking at the firmware revealed, that there is no stm32h7xx_hal_can.h available in the sthal.

So I wondered if CAN is available for the H7 as described on the product page?
If yes, how can I get a firmware which supports CAN?
Since it’s important to me, minor changes and compiling the firmware myself if necessary is an option.


Unfortunately CAN has changed significantly from F7 to H7 and there’s No driver in MicroPython. I started the support for H7 in upstream MicroPython but no one else has contributed a CAN driver yet. I could look into implementing a CAN driver for H7 soon.

We will have a CAN shield on sale soon so we can get this fixed. Please create a bug report on the github for this. The peripheral hasn’t changed much so it’s just some clock stuff that has to be dealt with.

Since we require CAN functionality as soon as possible (think next week) depending on what you mean by “soon” we would be willing to contribute.
iabdalkader - can you maybe pinpoint me to the location of the work you have already done?

Thanks for the quick replies

That would be great! Note no work has been done on the new CAN driver at all, anyway, here’s the STHAL FDCAN driver (it’s called FDCAN on H7):


This is our fork of MicroPython (all work is done in the openmv branch):

This is the old CAN driver you can base your work on this:

You can either fork our MicroPython and send a PR or send it upstream. If you send it to us it will get merged a lot faster, and I’ll send it upstream.


I am also very interested in CAN/CANFD on the H7. I have spoken with Damien at Micropython several times about this, and his time and focus has been on short supply to work on the new peripheral. As it has been pointed out the H7 is much more advanced and supports the CAN Flexible Data Rate, which many systems and devices to not utilize. My hope is there can be two stages where standard CAN 2.0A/B is supported with the new peripheral before full CAN FD functionality is worried about.

I personally do not have the time to work on the libraries, but willing to contribute to funding at least some of the efforts. CAN is used in almost all my products and projects and need it on a device to consider it.

While waiting to hear back from Damien on the next step with this I created an issue in their repo to help show support for the efforts on CAN for the H7.

If there are things I can do to help speed this up I would like to know. The price on the H7 chip is sometimes cheaper than the F7, and the CAN peripheral is the main thing in the way of me using it and working in the OpenMV H7 into some of my vision work.


Hi, there’s not much to do right now (unless you want start writing the driver) I’ve ordered some CAN transceivers and I’m going to work on adding basic CAN support for the H7 over the next weekend.

Hi, I can work on getting the CAN operational. I already have the new CAN shield prototypes at home we are about to release. I’ll just make the default normal CAN stuff work.

(Looks like Ibrahim might get to this before me).

Hello thanks for he help with supporting this.

Whether it is buying some boards or donating a little bit of funds to make this a higher priority I am happy to do one or both.

I hope the goal is that we can mimic the CAN capability of the F4/F7 on with Micropython, that would be ideal. FD functionality is probably needed by few at the moment, and where I believe most of the new complexity would come in.

Right now I am swamped with little projects I am already committed to, and for now the F7 and F4 chips work, so I do not have to move to the H7… but I want to :slight_smile:

I also want to use the new H7 OpenMV with some basic automation tools I am working on, and knowing the performance gain (latest silicon goes up to 480MHz now) This would be many times better than the current platforms that have CAN support.

Which transceivers are you planning to use/test with?

Thanks again and If we want/need to move a conversation off the forums just message me your email.


I ordered MCP2551 but I think we’re using something else in our CAN shields.

Here’s the design. It’s tested and works.

Sounds great :slight_smile:
Can you keep us posted on how things are turning out?
Especially if you don’t find the time to work on it, so we know if we have to find a plan B to finish our project on time.


The production run of the CAN shields are done. I will get samples soon. I’ll send some to Ibrahim so he can write his driver.

Hi can anyone help me test the FDCAN driver ? If you have 2x H7 and 2x CAN transceivers let me know and I’ll send you a firmware image for testing.

Great :slight_smile:
I have two h7 and two can transceiver which were working with the M7 here.


Great, attached a firmware image that enables FDCAN. You just need to test with something like this:

from pyb import CAN
can.send('Hello', 123)# send message with id 123

from pyb import CAN
print(can.recv(0, timeout=10000))  # receive message on FIFO 0

firmware.zip (936 KB)


I’m afraid the image does not work yet. At least there is no signal appearing on neither the GPIOs nor the transceiver output, when sending data.
Could you maybe push your changes to a branch on your fork, so we can debug what’s happening?


Hi Stefan,

There’s an open PR here with all my changes:

Hello there,

I’m currently using a M7 cam and I am planning to switch to the new H7. However CAN is mandatory in my application.
Could you give me an update about the work you are doing on implementing CAN bus on the new H7 ?

I see this comment in the PR : “This driver has been tested in loopback mode and with a two node transceiver-less network. However, it could use a lot of improvements especially with filters, interrupts and error handling, rxcallback etc…” Does it mean that filter is not yet implemented at all ? Because, in my opinion, filtering is a necessary feature when dealing with CAN.

Thank you for your answer.

No basic filtering has been implemented, however the driver still needs some more work. I’ll continue working on the driver this month, should be ready with the next release. Also MicroPython developers will help with the driver hopefully after they finish up their release.