RP2350 with PSRAM Intermittent Fails after POR or Reset

[eightycc]

CircuitPython version

Adafruit CircuitPython 9.2.0-45-g68cdc535b2-dirty on 2024-11-29; Pimoroni Pico Plus 2 W with rp2350b

Code/REPL

Any `code.py` or `main.py` will do.

Behavior

After power-on reset or button push reset, main.py or code.py script fails to start or terminates with a random error. More occasionally board will reboot into safe mode. Occurs on about 1 in 10 attempts. Only seeing this on PSRAM equipped boards. There is also a very long pause varying up to 5 seconds before the CP version message appears.

Description

No response

Additional information

No response

[bablokb]

I have never encountered this error but I haven't used this specific CP version but mainly something older like 9.0.x and 9.1.x. The boards I use are the iLabs Challenger-RP2350+Wifi/BLE (8MB PSRAM, A-type chip), Pimoroni Pico-Plus-2 and Pimoroni Pico-Plus-2W. The last two have 8MB PSRAM and the B-type chip and the last one was definitely tested with a post 9.2.1 version (board support was added after 9.2.1).

When I am back home I will retest with the most current CP-version to see if I can reproduce this.

[eightycc]

@bablokb This one is more difficult to reproduce than I've described it. I just retried a few dozen times and cannot get a fail.

Before we chalk this up to random noise in my head there is an RP2350 XIP cache maintenance operation that is missing from CP: The cache is not purged during port initialization, so when coming out of initialization after a reset stale cache entries may persist. Whether that's a real problem depends on whether or not the RP2350 purges the cache on a non-POR reset.

Pico SDK 2.1.0 provides a new set of XIP cache maintenance operations that include proper invalidate, clean, and pin. Calling for a complete cache invalidation early in port init would be a safe way of ensuring the state of the XIP cache. Also, #9783 implements an RP2350-specific cache clean that can be replaced by calling a generic SDK function.

@dhalbert What do you think?

[tannewt]

The cache is not purged during port initialization, so when coming out of initialization after a reset stale cache entries may persist.

I think the BootROM may do this before calling the application.

[eightycc]

I think the BootROM may do this before calling the application.

That's what I thought, but the code says otherwise. I can see where it might make sense to leave cache maintenance up to the app. For example, an app may want pinned cache lines to persist across a non-POR reset.

[tannewt]

Are you looking at the BootROM code? I'm pretty sure pinned cache lines are wiped out unless you use the special wake function stuff. Section 4.4.1.3:

The bootrom clears the tag memory upon entering the flash boot or NSBOOT (USB boot) path, but watchdog scratch vector reboots can boot directly into pinned XIP cache lines.

[eightycc]

Are you looking at the BootROM code?

Yes. There's a single entry point to s_varm_api_crit_flash_flush_cache_impl which implements the complete cache invalidation. Aside from linkage through the dispatch table for the SDK I cannot find any other calls. Maybe I'm missing something?

[dhalbert]

I have tried this with a Feather RP2350 with PSRAM installed a couple of dozen times and could not reproduce. Do you think it might have anything to do with the wifi co-processor?

[eightycc]

@dhalbert My lab techniques were a bit off on this one. I too have been unable to reproduce this bug. Please close it.