Implement Microchip SAM family CAN controller driver

[stephanosio]

Summary

A number of Microchip (formerly, Atmel) SAM family SoCs include a CAN 2.0A/B and CAN-FD capable host controller peripheral.

In order to take advantage of this, it is necessary to implement a driver for it, that can interface to the existing Zephyr CAN protocol stack.

Target Devices

The following Microchip SAM family devices implement the "Microchip CAN Controller" peripheral:

• SAM C21
• SAM E51/E54
• SAM E70
• SAM V70/V71

Note that the following (old generation) Atmel SAM family devices also include a CAN controller peripheral, but this is completely different from the "Microchip CAN Controller" and therefore incompatible; this issue does not propose to support them:

• SAM 3X
• SAM 4E

[stephanosio]

Is anyone already working on this by any chance?

cc @benpicco @nandojve @mnkp @aurel32 @karstenkoenig @alexanderwachter

[alexanderwachter]

Not that I know off. Do you plan to work on that driver by any chance?

[stephanosio]

Not that I know off. Do you plan to work on that driver by any chance?

Not anytime soon, but it is in my long-term backlog for now.

[nandojve]

I'm not working...happy to read that!

[DarrylGamroth]

FYI: those Microchip (formerly Atmel) products implement Bosch M_CAN IP. The same IP is used by ST (FDCAN) and TI (TCAN4550) so there may be value in having a generic driver.

[alexanderwachter]

I just implemented the driver for STM32G4 (FDCAN) #22832

[stephanosio]

FYI: those Microchip (formerly Atmel) products implement Bosch M_CAN IP. The same IP is used by ST (FDCAN) and TI (TCAN4550) so there may be value in having a generic driver.

@DarrylGamroth Comparing the CAN FD register maps of the SAM and STM32 SoCs, I can see that is indeed the case. Thanks for the very useful info!

I just implemented the driver for STM32G4 (FDCAN) #22832

@alexanderwachter It looks like it would be possible to support the Atmel SAM series just by refactoring your "STM32" CAN FD driver in that PR :)

[karstenkoenig]

Not working on any CAN drivers lately :-(

@DarrylGamroth Oh wow thanks for pointing that out! I knew the TCAN4550 standalone controller had a bosch m_can ip but not that it's also what's in the STs FDCAN. The TCAN4550 looked really sweet, but the price of that evaluation board is just a bit much...

[alexanderwachter]

@DarrylGamroth thanks for pointing this out! I‘ll rename the driver then!

[alexanderwachter]

I separated the generic part of the M_CAN module. Some functions need to be implemented for every platform, like all clock related stuff. Unfortunately, the STM FDCAN is not 100% compatible with M_CAN. It misses some registers, and the size of the message RAM differs. There will be some #ifdefs in the code.

[DarrylGamroth]

Nice!

Could the message RAM definition be defined in Devicetree similar to the Linux dts then use DT_REG_ADDR_BY_NAME(DT_INST(0, bosch_m_can), message_ram) to get the base and DT_REG_SIZE_BY_NAME(DT_INST(0, bosch_m_can), message_ram) for the size?

I might be wrong with the correct DT macro usage but you get the general idea.

[alexanderwachter]

Sure, it is not finished yet. There are some other things, especially in the init, that need to be changed.

[Urist-McGit]

I am currently working on a M_CAN driver specialization for the SAMV71 series. My current progress can be found here: https://github.com/Urist-McGit/zephyr/commits/can_mcan_samv71_driver

The work is done for the most part. I am unfortunately stuck on a problem very likely related to the message ram. To summarize the current progress: the driver sends and receives messages on the right pins, with the correct bitrate etc. But unfortunately I receive and send somewhat random messages, sometimes all zero, sometimes random garbage, sometimes the right message. All testing is currently done in normal, not CANFD mode, since I only have a USB2CAN dongle.

I would be very glad to accept some guidance with my problem. I think it would be useful to have the collaboration in a WIP PR or something like that, where I could also lay out the exact way I test the driver, what hardware I test on etc. I am open to any other suggestions though. Thanks in advance!

[alexanderwachter]

@Urist-McGit can you write a message in the canbus slack channel? Michael Albrechr, @legoabram and me already solved this problem. It is the cache! You need to invalidate the caches after a write and before a read of the msg_sram

[henrikbrixandersen]

@Urist-McGit The cache invalidation fix for the common M_CAN driver code is in the main tree now. Do you plan on picking up your work on the Atmel SAMV71 M_CAN driver front-end?

[Urist-McGit]

@henrikbrixandersen After a discussion on the zephyr slack channel, I found out that @legoabram and Michael Albrecht had already implementented a prototype of the specialization before me. They did not mention it anywhere here so I unfortunately redid their work for the most part. Have you tried pinging them? They should be able to help you :) It has been quite some time since I touched the code, but if I remember correctly, my code worked for the samv71 revision B board and support for revision A was in the works. My company has since moved on from the project and I dont have the hardware at hand anymore. I won't be able to finish it, but maybe someone can pick up the work.

[alexanderwachter]

incoming...

41674