zephyr: [same70] CAN driver maybe broken?

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 image

with CAN sniffer on zephyr-3.5.0 image

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.

About this issue

  • Original URL
  • State: open
  • Created 5 months ago
  • Comments: 17 (17 by maintainers)

Commits related to this issue

Most upvoted comments

My suggestion is add this address in the DTS to map using devicetree. So, the system can proper handle with each instance. It could be a new property named dma_base_reg with a very good description.

It could also just be a new, named entry in the regs property, which is intended for this. I’d prefer that approach.

Solution 1 is the way to go. You’ll need to program the 16-bit MSB of the address into the register (for both CAN0 and CAN1).