[same70] CAN driver maybe broken?

[tswaehn]

I am really curious. Working with zephyr 3.0.0 CAN drivers was like charm. worked out of the box. However turning to zephyr 3.5.0 things seem to be a bit different - made all changes that come with zephyr 3.5.0 and still I cant get it running.

my test setup:

• same70q21b
• minimal zephyr program
• can init
• can test sends a single message every 100msec
• works fine in zephyr-3.0.0 - fails in zephyr-3.5.0

this is the test code for zephyr-3.5.0 below:

• maybe I am missing something important here?
• for every message I send -- I get a Remote Transmission Request (double checked with CAN sniffer)

void main(void){

    can_init(CAN_BAUDRATE);

    while(1){
        can_test();
        k_sleep(K_MSEC(100));
    }

}

void can_init(uint32_t baudrate) {
    int32_t ret;

    const struct can_filter std_filter = {
            .id = CAN_STD_ID_MASK,
            .mask = 0,
            .flags = 0,
    };

    can.dev = device_get_binding("CAN_0");
    if (can.dev == NULL) {
        LOG_ERR("unable to get CAN_0 device");
        return;
    }

    if (0 != can_set_baudrate(baudrate)) {
        return;
    }

    can_start(can.dev);
}

void can_test(){

    struct can_frame frame = {
            .flags = 0,
            .id = 0x123,
            .dlc = 5,
    };

    for (uint32_t i = 0; i < 5; i++) {
        frame.data[i] = 0x11 * i;
    }

    int32_t ret = can_send(can.dev, &frame, K_MSEC(100), NULL, NULL);

   //it always returns ret=0 !!!

    if (0 != ret){
        // error
        LOG_ERR("failed to send CAN message");
    } else {
        // success
    }

}

update

with CAN sniffer on zephyr-3.0.0

with CAN sniffer on zephyr-3.5.0

in summary it looks like the

• header is damged somehow ID and DLC is incorrect
• first byte is different, not sure what this is for

update

it looks like taking the complete wrong buffers in zephyr-3.5.0 for sending; it always sends the data, that was used before in the test with zephyr-3.0.0 which are still present in RAM.

[tswaehn]

@henrikbrixandersen from the source it looks like you are the expert on can_sam.c did you notice anything or could you confirm seeing can messages at a can-sniffer tool in general with zephy 3.5.0 (not loopback)?

[tswaehn]

it looks like this is can_sam specific. the offset register for the message ram offset is by default REG_CCFG_CAN0 = 0x20400000

however the driver comes up with sam_cfg->mram = 0x2041b40. (actually I dont know where this value comes from??)

nevertheless -- this dosnt fit together.

• we may want to correct the driver value of sam_cfg->mram
• or post update the REG_CCFG_CAN0 accordingly

this brings back writing to can in zephyr-3.5.0 to kind of normal (not yet sure about side effects)

(result of example from above)

[henrikbrixandersen]

Please retest this on the v3.5-branch (making sure commit 8415778 is included in your branch when testing). Testing on main would also be nice.

[henrikbrixandersen]

• or post update the REG_CCFG_CAN0 accordingly

Yeah, I've previously raised an issue about CCFG_CAN0:CAN0DMABA and CCFG_SYSIO:CAN1DMABA being left at default values (which may or may not be correct depending on where in memory the M_CAN message RAM is placed), but I was told changing it from the default would never be needed due to the memory layout of these MCUs.

I do not have access to any SAM/SAM0 hardware with M_CAN IPs embedded myself, so unfortunately I am not able to test and confirm this problem, nor test any fix writing to CCFG_CAN0:CAN0DMABA and CCFG_SYSIO:CAN1DMABA.

You may be able to find some inspiration as to how to solve this by using the handling of MRBA in https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/can/can_mcux_mcan.c#L82 as inspiration.

CC: @nandojve

[tswaehn]

the driver comes up with sam_cfg->mram = 0x2041b40

@henrikbrixandersen I am curious where this value comes from. its not the initial value. why should that be changed in first place?

[tswaehn]

Please retest this on the v3.5-branch (making sure commit 8415778 is included in your branch when testing). Testing on main would also be nice.

Please note that I already did test with zephyr 3.5; I also confirmed that patch 8415778 is included.

So the issue persists and is valid - open

[henrikbrixandersen]

Please note that I already did test with zephyr 3.5; I also confirmed that patch 8415778 is included.

Do you have CONFIG_CACHE_MANAGEMENT=y and CONFIG_DCACHE=y both enabled?

[henrikbrixandersen]

the driver comes up with sam_cfg->mram = 0x2041b40

@henrikbrixandersen I am curious where this value comes from. its not the initial value. why should that be changed in first place?

The SAM/SAM0 series do not have dedicated RAM for the Bosch M_CAN message RAM, so the driver allocates a memory area for this using CAN_MCAN_DT_INST_MRAM_DEFINE(). The value, you are seeing, is the address of this area in RAM.

I am not sure what you mean by "initial value" and why you think this needs to be changed?

[nandojve]

Hi @tswaehn , @henrikbrixandersen ,

Unfortunately I can not test MCAN and don't have knowledge about CAN protocol. What I know is that there is a lot of issues around cache these days and we need to be careful. I recommend that you try after this #66524, maybe v3.6.0-RC1, to make sure you have all patches in. Since Atmel is only supported by community we only track the main branch but, eventually, there is no problem to backport to old version as soon we have a solution in main.

So if you are backport an old version I recommend you to backport to v3.6.0-rc1 at moment.