sam: atsamc21: driver for CAN for SAMC21

[benys]

Driver was based on can_sam.

Signed-off-by: Kamil Serwus [email protected]

[henrikbrixandersen]

We will need a way of testing this - at least the compilation part. Can this be enabled on a board?

[benys]

We will need a way of testing this - at least the compilation part. Can this be enabled on a board?

This CAN works only with SAMCAN21x. I have in my solution connected to board intruduced at #50384 PR.
In my opionion I should add connection to board/soc after merged #50384? Becouse only C21 implements this SAM0_CAN

BTW In my repo it fully works. You can check my old commit: benys@55559a8

[henrikbrixandersen]

Okay. I suggest postponing this to after #50384 is merged, then. That was the initial feedback given in that PR as well.

[alexanderwachter]

Please provide a meaningful commit message

[str4t0m]

Converted to a draft for now, as board files still need to be added after #50384 was merged.

[benys]

@henrikbrixandersen i have a problem, that CAN can send messages (i receive messages by CAN usb stick), but when I send by CAN usb stick - i don't receive interrupt.
I set this filter:

    const struct can_filter change_led_filter = {
		.id_type = CAN_EXTENDED_IDENTIFIER,
		.rtr = CAN_DATAFRAME,
		.rtr_mask = 1,
		.id_mask = 0
	};

    ret = can_add_rx_filter_msgq(can_dev, &can_msgq, &change_led_filter);
	if (ret == -ENOSPC) {
		printk("Error, no filter available!\n");
		return;
	}

Do you have idea what I have to check?

[henrikbrixandersen]

Do you have idea what I have to check?

First off, do the CAN API tests pass in loopback mode? Once the CAN API tests pass in loopback mode - and if the problem persists:

• Have you tried using the CAN shell for testing?
• Are the pinctrl settings correct?
• Is the CAN interrupt enabled correctly?
• Is the CAN interrupt triggered at all?
• Have you tried using a debugger to examine what happens?

[benys]

@henrikbrixandersen

• Have you tried using the CAN shell for testing?

Not yet, but I run sam counter sample. And I extend it a litte bit. On loopback mode it fully works. With external CAN commands it not handle incoming CAN frames.

• Are the pinctrl settings correct?

I tripled checked. I honestly I port my application which originaly used plain ASF4. So I checked pinctrls by comparison one-to-one. TXpin works becouse it send data. SO i believe that in in zephyr RXpin also is corecrly connected.

• Is the CAN interrupt enabled correctly?

Yes, but I have idea that problem is that zephyr mcan driver uses two interrupts per device, but SAMC has only one line. I tried investigate, that maybe mcan driver set to use second interrupts for incoming data from external world.

• Is the CAN interrupt triggered at all?

Yes for example:

LED ON
[00:00:05.004,000] <dbg> can_mcan: can_mcan_send: Sending 2 bytes. Id: 0x12345, ID type: extended   
[00:00:05.004,000] <dbg> can_mcan: can_mcan_send: Waiting for TX complete
[00:00:05.005,000] <dbg> can_mcan: can_mcan_line_1_isr: RX FIFO0 INT
[00:00:05.005,000] <dbg> can_mcan: can_mcan_get_message: Frame on filter 28, ID: 0x12345
Counter received: 2
[00:00:06.005,000] <dbg> can_mcan: can_mcan_send: Sending 1 bytes. Id: 0x10, ID type: standard   
[00:00:06.006,000] <dbg> can_mcan: can_mcan_line_1_isr: RX FIFO0 INT
[00:00:06.006,000] <dbg> can_mcan: can_mcan_get_message: Frame on filter 0, ID: 0x10

• Have you tried using a debugger to examine what happens?

Yes :-) without debugger it is inposible to investigate :)

I will try check with second interupt for bosch IP. If you have some ideas please give me :)

[alexanderwachter]

Looks like the loopback mode works.
That means it is likely that it is either pinctrl, or a problem wit the bus (baudrate, termination, issue with the transceiver, ...)

[benys]

@henrikbrixandersen and @alexanderwachter i think that i found I receive some of messages.
I forget that "if you work with can you must found mcan datasheet" :)

#ifdef CONFIG_CAN_STM32FD
	can->ils = CAN_MCAN_ILS_RXFIFO0 | CAN_MCAN_ILS_RXFIFO1;
#else
	can->ils = 0;//CAN_MCAN_ILS_RF0N | CAN_MCAN_ILS_RF1N;
#endif
	can->ile = CAN_MCAN_ILE_EINT0; //| CAN_MCAN_ILE_EINT1;

in mcan driver was implemented that some interrupts was handled by second line.
So I have a question - you recomend add elif CONFIG_CAN_SAM0 ? with fixed declaration for SAMC?

BTW i need now investiage why have many bus_off state.

[henrikbrixandersen]

So I have a question - you recomend add elif CONFIG_CAN_SAM0 ?

You can add that for now. I am working on getting rid of all platform specific code in the M_CAN backend driver, though.

[benys]

@henrikbrixandersen @alexanderwachter i had last problem (i hope). NBTP computation.
I discovered that zephry compute this registry as:

generation from zephyr

• ntseg2=3
• ntseg1=26
• nbrp=0

so

• tq = 1
• ntseq1+ntseg2+3=32
• product = 32*1=32

my original sample

• ntseg2=0
• ntseg1=1
• nbrp=7

so

• tq = 8
• ntseq1+ntseg2+3=4
• product =4*8=32

But first sample - produces a lot of receive errors (counter is not zero) and my second samples works very well.
Did you have same problems in the past? How can I handle this problem?

[alexanderwachter]

Well, you can set the sample point a bit earlier to meet your old values. However, the sample points used by Zephyr are recommended by the CiA

[fabiobaltieri]

@benys can you rebase please?

[benys]

@benys can you rebase please?

I rebased, but I will it test +- tommorow at the office :) I will inform you.

[silverv]

I tested the code before rebase and after rebase on my very reputable hardware (https://ww1.microchip.com/downloads/en/DeviceDoc/70005318A.pdf) and I have some observations.
The rebased code fails (didn't fail before rebase) if you do this on an astamc21n18a, running the samples/drivers/can/counter example code:

1. Set loopback mode on the example off
2. Set bitrate to match the can adapter
3. Connect CAN to an adapter
4. Observe how the can driver fails to start at line 215: printf("CAN: Device %s not ready.\n", can_dev->name);
5. With logging enabled CONFIG_LOG=y, the mcan driver will report an init failure.
   Both CAN0 and CAN1 work before rebase on the previous 81afde13448808f71b12c4bacc18d9ef4f6649ec commit, I still have it locally and I am using it for another custom board.

[benys]

@silverv @henrikbrixandersen i little fixed my PR, but after rebase still not works :-(
I am still looking reason...

EDIT:
I discovered that it brokes at commit "drivers: can: mcan: move message RAM configuration to front-end drivers"

EDIT2 @henrikbrixandersen
I discovered that for SAM0 can_mcan_configure_message_ram need be executed "can_mcan_enter_init_mode" before or first at can_mcan_configure_message_ram like:

I don't know that I can include it at my change? Or remove static attribute can_mcan_enter_init_mode to execute it form sam0 driver level

[henrikbrixandersen]

Thanks!