CAN issue with NUCLEO

The official pyboard running MicroPython.
This is the reference design and main target board for MicroPython.
You can buy one at the store.
Target audience: Users with a pyboard.
Post Reply
Posts: 8
Joined: Tue Jul 02, 2019 1:49 pm

CAN issue with NUCLEO

Post by pthwebdev » Mon Jul 08, 2019 6:43 pm

I have a setup with two devices interchanging CAN messages. To this setup I added a NUCLEO_F746ZG. A message sent from the NUCLEO is received by both other devices. So I know I have the baudrate correct. However, can.recv(0) never returns a message. It always times out (OSError: [Errno 110] ETIMEDOUT). Even in LOOPBACK (as per the example) it always times out.

In order to rule out hardware issues (a loose wire, a blown port pin or the tranceiver malfunctioning) I flashed some of my own firmware onto the NUCLEO. With that firmware both sending and receiving works correctly.

I have expressly called initfilterbanks, but that does not make any difference.

What is the magic word to receive can messages?

Posts: 8
Joined: Tue Jul 02, 2019 1:49 pm

Re: CAN issue with NUCLEO (SOLVED)

Post by pthwebdev » Wed Jul 10, 2019 8:29 am

Great Scott, this is embarrassing.

No filter, no data! At all. Null, nada, zip, zilch.

My assumption, as on other platforms where I work with CAN, was that no filter meant all data.

It seems to be that calling initfilterbanks, of which the documentation says it disables all filters, means that nothing will pass. I thought it meant that filters were deactivated so everything would pass.

So with

Code: Select all

can1.setfilter(0, CAN.MASK16, 0, (0x3FF, 0, 0, 0))
can1 will receive all standard identifiers and with

Code: Select all

can2 = CAN(2, CAN.LOOPBACK, extframe=True)
can2.setfilter(0, CAN.MASK32, 0, (0x1FFFFFFF, 0))
can2 will receive all extended identifiers

From the lack of response I gather:
- no one is using NUCLEO boards
- or people use NUCLEOs, but no one uses CAN
- or people use NUCLEOs and use CAN, but were not having this particular problem.

I tested it on another board (using a STM32F407VET6) and that behaves exactly the same.

Anyway, may this be a lesson that helps all of us.

Post Reply