Not working on RP2350

[xrip]

When building example with -DPICO_PLATFORM=rp2350-arm-s it stucks on first 8-bit writes.

[benb123]

Yes I have a similar issue. I was wondering could it be the something to do with the Pull Down (or floating) GPIO issue with the Pico 2? I tried added a PULL UP to the relevant pins but no diff.

[xrip]

May be this issue would be solved if we switch to develop branch on Pico-SDK, but i can't test it cause dont have pico 2 right now

[benb123]

Well I switched to the develop branch tonight on your suggestion. I tried standard 150Mhz, 200 and 400Mhz system clocks. Same results.

I can see the CLK, CS and MOSI lines are looking OK to the PSRAM but MISO never seems to transition like it does on the RP2040.

I put an external 10K pullup resistor on MISO and it did go HIGH but never LOW. This makes me think if I disconnected the PSRAM from MISO only, it would likely stay LOW.

So, it appears that the PSRAM does not like what it receives from the Pico 2 and isn't responding. Has the timing changed between RP2040 and RP2350 I wonder?

[DnCraptor]

May be related:

The Pico 2 has been released in a basically useless status. It has been detected a bug in the GPIO hardware that locks the pins whenever you input a high level, what is known as "Errata E9". According to the official errata the lock only happens when the pull downs are enabled, you input a high level value and then the GPIO starts outputing 2.1v. That doesn't sounds too bad but the reality is very different. I've been testing it and even forcing the pulldowns to be disabled, the PIO triggers the lock. In this state, the RP2350 is useless if you need to use the GPIO's to input any data. The only workaround provided is to disable the pins and enable them when you are going to read and disable them after it to reset the pin status, but as you can imagine with the PIO this is impossible, and even if it was possible the capture speed would be reduced so much that the analyzer would be totally useless. see: https://github.com/gusmanb/logicanalyzer

[polpo]

FYI I have had no problem with this library on the PicoGUS when porting to the Pico 2, but it may be just in the way I'm using it. I'll make sure my example code actually works.

I mostly disagree that the Pico 2 has been released in a "basically useless status." The RP2350 Erratum E9 means that there's a leakage current of 120uA on each GPIO that must be overcome and the PSRAM chip should have no problem doing that. It should not be a problem if you're interfacing the Pico with devices with TTL push/pull outputs.

[xrip]

Im using your master HEAD with following pins

            PSRAM
            PSRAM_SPINLOCK=1
            PSRAM_ASYNC=1

            PSRAM_PIN_CS=18
            PSRAM_PIN_SCK=19
            PSRAM_PIN_MOSI=20
            PSRAM_PIN_MISO=21

And it's works absolutely fine on RP2040 and not works at all with RP2350

[DnCraptor]

FYI I have had no problem with this library on the PicoGUS when porting to the Pico 2, but it may be just in the way I'm using it. I'll make sure my example code actually works.

Or pls. just provide example extracted from the PicoGUS code (in case it will be with related el. schema, it will be great)

[benb123]

FYI I have had no problem with this library on the PicoGUS when porting to the Pico 2, but it may be just in the way I'm using it. I'll make sure my example code actually works.

I mostly disagree that the Pico 2 has been released in a "basically useless status." The RP2350 Erratum E9 means that there's a leakage current of 120uA on each GPIO that must be overcome and the PSRAM chip should have no problem doing that. It should not be a problem if you're interfacing the Pico with devices with TTL push/pull outputs.

I wonder if it is because you try first without the fudge then the fudge?

psram_spi = psram_spi_init_clkdiv(pio1, -1, psram_clkdiv / clkdiv /, false / fudge /); .. ram test ... if ... ram test failed... psram_spi = psram_spi_init_clkdiv(pio1, -1, psram_clkdiv / clkdiv /, true / fudge /); ...

[DnCraptor]

FYI: all my attempts to launch psram_spi on RP2350 are failed. Last attempt was related to W/A documented - added resistor 4.7kOm to GND from input pin (5-th on PSRAM ESP32-64H chip). It still works as expected on RP2040, but failed on new chip. Also, attempt to try fudge/no-fudge init was failed too.

[benb123]

@polpo I have analysed the picogus code and pretty much replicated the same approach, changed the clkdiv to slower and faster settings, used 366MHz like picoGUS (and the same clkdiv).

Even the schematic is very similar to mine except for the PSRAM (same module, no resistors) I am using:

PSRAM_SPINLOCK=1
PSRAM_PIN_MISO=16
PSRAM_PIN_CS=17
PSRAM_PIN_SCK=18
PSRAM_PIN_MOSI=19

Stumped.

[DnCraptor]

Some (good) news from my side - it works! I moved PSRAM chip from:

#        PSRAM_PIN_CS=18
#        PSRAM_PIN_SCK=19
#        PSRAM_PIN_MOSI=20
#        PSRAM_PIN_MISO=21

to

        PSRAM_PIN_CS=17
        PSRAM_PIN_SCK=18
        PSRAM_PIN_MOSI=19
        PSRAM_PIN_MISO=16

and it started to work. It was testd with and without 4.7k resistor from pin-5 to GND - it works in both cases. Related defines:

        PSRAM
        # PSRAM_MUTEX=1
        PSRAM_SPINLOCK=1
        PSRAM_ASYNC=1

Related initialization for the library:

static psram_spi_inst_t psram_spi;

#define ITE_PSRAM (1ul << 20)
#define MAX_PSRAM (512ul << 20)

static uint32_t _psram_size() {
    int32_t res = 0;
    for (res = ITE_PSRAM; res < MAX_PSRAM; res += ITE_PSRAM) {
        psram_write32(&psram_spi, res, res);
        if (res != psram_read32(&psram_spi, res)) {
            res -= ITE_PSRAM;
            return res;
        }
    }
    return res - psram_read32(&psram_spi, ITE_PSRAM) + ITE_PSRAM;
}

uint32_t psram_size() {
    static int32_t _res = -1;
    int32_t res = 0;
    if (_res != -1) {
        return _res;
    }
    _res = _psram_size();
    return _res;
}

uint32_t init_psram() {
    psram_spi = psram_spi_init_clkdiv(pio0, -1, 2.0, false);
    if ( !_psram_size() ) {
        psram_spi = psram_spi_init_clkdiv(pio0, -1, 2.0, true);
    }
    return psram_size();
}

[DnCraptor]

FYI: other initialazation code was tested (also for GPIO 16-19, async):

extern psram_spi_inst_t psram_spi;
static __always_inline bool init_psram() {
    psram_spi = psram_spi_init_clkdiv(pio0, -1, 2.0f, false);
    psram_write32(&psram_spi, 0x313373, 0xDEADBEEF);
    bool PSRAM_AVAILABLE = 0xDEADBEEF == psram_read32(&psram_spi, 0x313373);
    for (uint32_t addr32 = (1ul << 20); addr32 < (2ul << 20); addr32 += 4) {
        psram_write32(&psram_spi, addr32, 0xFF);
    }
    return PSRAM_AVAILABLE;
}

Also, it may be interresting for you - first case (from prev. post) was tested on CPU overclocked up to 366MHz, using:

    vreg_set_voltage(VREG_VOLTAGE_1_40);
    sleep_ms(10);
    set_sys_clock_khz(CPU_MHZ * KHZ, true);

and this one was tested in other application on 444MHz, overvoltaged up to 1.6v. Timings used:

    volatile uint32_t *qmi_m0_timing=(uint32_t *)0x400d000c;
    vreg_disable_voltage_limit();
    vreg_set_voltage(VREG_VOLTAGE_1_60);
    sleep_ms(33);
    *qmi_m0_timing = 0x60007204;
    set_sys_clock_hz(444000000, 0);
    *qmi_m0_timing = 0x60007303;

[benb123]

@DnCraptor. That was interesting how it worked for you using the same pin configs as mine but it didn't work until I added the missing line below into the psram_spi.pio file:

pio_sm_set_consecutive_pindirs(pio, sm, pin_cs, 2, true);
pio_sm_set_consecutive_pindirs(pio, sm, pin_mosi, 1, true);
pio_sm_set_consecutive_pindirs(pio, sm, pin_miso, 1, false);
pio_gpio_init(pio, pin_miso); // MISSING this initialisation of the incoming PIN!
pio_gpio_init(pio, pin_mosi);
pio_gpio_init(pio, pin_cs);
pio_gpio_init(pio, pin_cs + 1);

Now it works for me! :-)

Could you just check if your code is somehow initialising that pin_miso GPIO somewhere else?

PS nice 444MHz overclock. I was using 400 but I might push it higher as that does work for me also with your 1.6v setting and other timing configs I am not familiar with. Are they necessary?

[polpo]

Aha - that’s the difference that I missed! RP2350 requires that pins must be explicitly enabled for input unlike on RP2040 where they are enabled by default. I will update the library to init the MISO pin so its input is enabled.

[DnCraptor]

Today was found, that I used the same pin for joystick, and this code was not disabled on re-pinning, so, may be, it was initialized just by other driver (will investigate).

[DnCraptor]

pio_gpio_init(pio, pin_miso); // MISSING this initialisation of the incoming PIN!

Tested on by pins - GPIO 18-21. Works ok. Thnx for your investigation!