Weird occassional SPI performance glitches on RP2350A0A2

[xoblite]

Hi all,

I bought a couple of Pico 2 (RP2350A0A2) on launch day, to ultimately replace Pico 1 (RP2040xxxx) in a product design of mine. Overall the RP2350 has been very impressive performance-wise, but I've also experienced a few unexplainable glitches along the way, most prominently some weird occassional SPI performance glitches where I could see the calling loops drop by a factor 100x or so in performance (e.g. from ~70000 cycles per second down to ~700 cycles per second for one of said loops, i.e. not to standstill but very low performance).

When this would happen, this performance degradation would persist across power off/on's, re-compile/upload of the SW, etc, sometimes over longer periods, only to suddenly jump back to regular performance at some point after a re-compile/upload of the SW, without the SPI parts having been touched in between the re-compilation rounds. At first, as the drop in performance was so significant I could not really understand what might be causing it, but I of course checked e.g. for possible mutex issues, contentions etc but could not find any. Then, when I suddenly got the performance back without seemingly touching anything related, I became increasingly suspicious: Could this be a (Windows and C in my case) SDK/lib/compiler/etc issue not yet ironed out in 2.0.0? Then I learned about RP2350-E9, and wondered instead if this could somehow be related to what I had experienced? Of course, with the performance at least for the time being back to normal, there's not much I can to in terms of further tracing, but I figured I should post this here in case someone else has experienced something similar, or if someone might be able to provide comments/trace-backs/etc as to how this could possibly be triggered by or related to E9? (especially as I've never seen anything like it with the RP2040)

Thanks in advance!

BR//Karl

EDIT: Perhaps I should mention as well that in this particular design, I have the /CS chip selects implemented as two (or more) regular GPIOs routed into a SN74HC138 for demultiplexing into individual /CS lines per device. In other words, I don't use the default SPI0-SPI1 /CS lines as such. Mentioning this in case it's relevant for the E9 case investigation as per above.

[xoblite]

Cross-referencing the following post on the Raspberry Pi forums: https://forums.raspberrypi.com/viewtopic.php?t=376248

[xoblite]

Closing as new findings rather indicate problems elsewhere on the shared SPI bus, likely caused by a rogue device. (why these issues weren't seen prior to the migration to RP2350 is still unknown, but as it seems possibly coincidental).