RP2350B, pins on IO block 1 deadlock library

[spit4520]

Hi Kevin,

First off, great library! Thank you for all of your efforts :)

We were trying to use CAN on pins 38, 39 and assign to PIO 2, but the program enters a deadlock condition after we launch CAN. After reviewing the source code, I think there might be an issue related to the register manipulate for the SIO or the pad.

There are a lot of specific implementation details I would have to work through to determine what is going on with the register assembly, so I figured I would open up a ticket while I try and debug what is going on.

What steps did I do to rule out hardware?

• Same code, same circuit, just using GPIO's under 32 and PIO 0.
• Code + hardware worked as expected
• Tried different pins at or above GPIO 32 with consistent results

What haven't I tested?

• I have not extensively ruled out PIO 2 as a part of the problem, I think PIO 2 is probably fine, but I am including it in the problem statement.

@KevinOConnor is there a reason that you aren't using the PICO-SDK's functions for SM initialization and GPIO configuration? I understand why you might want to handle them directly, if you can lay out your design goals for the library I can submit a PR to hopefully help patch some of this :)

Thank you again for publishing this library, you are what makes Open Source awesome!

[KevinOConnor]

We were trying to use CAN on pins 38, 39 and assign to PIO 2, but the program enters a deadlock condition after we launch CAN.

It is possible there is an issue with using pins above gpio31, as I implemented that code from the spec and I did not have the hardware on hand to test it at the time. (I now do have the hardware, but I don't immediately have a test environment for it.)

The spec is not particularly complicated though. You can search the can2040.c code for gpiobase to see all the relevant code. Looking now, I don't see any immediate issues with the implementation.

You might want to try PIO0 with pins 38/39, just to rule out some unexpected interaction with PIO2. Also, triple check that PICO_RP2350 is defined in the C flags when compiling can2040.c .

is there a reason that you aren't using the PICO-SDK's functions for SM initialization and GPIO configuration?

Many users of can2040 (including my own use case in the Klipper software) do not use the pico-sdk. It is common for projects to go "bare metal" or to utilize other cross-platform frameworks (eg, freertos, zepheros). As such, I tried to avoid introducing unnecessary dependencies on pico-sdk.

Cheers,
-Kevin

[JarinKurashige]

I would like to point out another potential bug. The driver currently assumes that both the rx and tx pins are a part of the same gpiobase.

// Return the gpio bank offset (on rp2350 chips)
static uint32_t
pio_gpiobase(struct can2040 *cd)
{
    if (!IS_RP2350)
        return 0;
    return (cd->gpio_rx > 31 || cd->gpio_tx > 31) ? 16 : 0;
}

As the gpiobase can only address GPIOs 0-31 xor 16-48, if one tx or rx pin is on GPIO 0-15 and one is on GPIO 32-48, it appears that it would not be possible to address both GPIOs because the GPIO 32-48 would cause the pinbase to always be 16.

[KevinOConnor]

As the gpiobase can only address GPIOs 0-31 xor 16-48, if one tx or rx pin is on GPIO 0-15 and one is on GPIO 32-48, it appears that it would not be possible to address both GPIOs because the GPIO 32-48 would cause the pinbase to always be 16.

The rp2350 gpio range limitation is documented at https://github.com/KevinOConnor/can2040/blob/master/docs/API.md#can2040_start . It is a limitation of the hardware and not a choice of the software.

-Kevin