It looks like the SSI clock speed is indeed the culprit here. Decreasing it by doubling the PICO_FLASH_SPI_CLKDIV #define macro seems to eliminate the issue. I can then increase sysclk quite a bit (up to 270 MHz or so) before it starts being an issue again.
I'm still wondering where exactly the issue lies though. The SSI controller or SPI flash memory controller logic not being able to handle the fast clock? Crosstalk and interference in the traces on the PCB?
The PCB itself isn't particularly dirty (see here and here). It's a mess of wires, sure, but none of these are carrying any activity that could cause some sort of EMI at the moment of the crash. I suppose I could do some soldering and start swapping chips from different Pico boards to see which of the two would make a difference, but I'm going to shelve that for later.
I'm still wondering where exactly the issue lies though. The SSI controller or SPI flash memory controller logic not being able to handle the fast clock? Crosstalk and interference in the traces on the PCB?
The PCB itself isn't particularly dirty (see here and here). It's a mess of wires, sure, but none of these are carrying any activity that could cause some sort of EMI at the moment of the crash. I suppose I could do some soldering and start swapping chips from different Pico boards to see which of the two would make a difference, but I'm going to shelve that for later.
See above, plus in the OP I already concluded that it cannot be a simple software issue. I don't think there is a single explanation for this behavior where the root cause would be a software problem. (Also, "just an apt install", I don't have root on this work machine (it does run Linux), so that's either compiling GCC myself or going through more bureaucracy.)If the new Pico doesn't work that would suggest an issue with your development setup, software or configuration.
Statistics: Posted by triss64738 — Fri Oct 25, 2024 12:49 pm