Garbled config menu screen, pico clone will not save settings

[MarkMccabe]

I am testing the clone pico with the version V0.2 SIDKick PCB with no DAC installed. I am using firmware V0.211 file "SKpico2_PWM.uf2".
I am using an older revision C64 with the 5 pin video (board 326298) and I have the same issue. I have read that they may have timing issues with the SIDKicks and some have suggested setting the timing to 6 and 6.
Regardless of what timing values I use, half the time the config menu will come up but it is garbled, the other half of the time I get a "timing issue" message instead. When the menu does come up, it looks like this. The firmware revision display is garbage, I can select 6581 for SID1 and none for SID2, I can not change the SID-Clock from anything other than DREAN (I am on a NTSC machine). Music plays if I press "P". I can get to the programs menu and they load and run fine.
However when I restart the computer, all the changes I have made and saved are gone and I am back to the same garbled config screen.
The weird thing is if I use a different pico clone from the same batch of 10 that I ordered (just like the ones used by FRNTC) everything will work fine as it should, but about half of the batch of 10 that I purchased have this same errant behaviour.
I tried many different timing changes. Are we absolutely sure there are no timing issues reading/writing to the flash (I have the 16M flash models)? I am at a loss, and any help/guidance on timing tweaks I should make using SKPicoPatch would be wonderful, or is it just that about half the black clones are defective in some manner?
This is similar to the discussion that were being made in discussion 39 last year, and updates on a resolution?
I am just about ready to toss all 10 sets in the trash and start over with the newer SIDKick with the DAC and pico built onboard, but that will have made everything purchased to date a total loss. HELP :)

[frntc]

Whenever you get a timing warning/error, the menu is garbled, or doesn't start then you have a bus communication issue -- as long as everything else is functioning, it's a timing issue (and it doesn't make sense to configure the SKpico or save the configuration, as the data cannot be read/written reliably to flash).

I have experienced bad build quality of the Pico clones (50% failure seems high though), but I'd say: if you exchange the Pico and this changes the behavior, then it's the Pico ;-) Can you confirm that they all use the same components? (mainly the flash IC)

[MarkMccabe]

They look like Winbond 25Q32JV (8 pin)
The data sheet says: "The W25Q32JV supports the standard Serial Peripheral Interface (SPI), and a high performance Dual/Quad output as well as Dual/Quad I/O SPI: Serial Clock, Chip Select, Serial Data I/O0 (DI), I/O1 (DO), I/O2, and I/O3. SPI clock frequencies of up to 133MHz are supported allowing equivalent clock rates of 266MHz (133MHz x 2) for Dual I/O and 532MHz (133MHz x 4) for Quad I/O when using the Fast Read Dual/Quad I/O instructions. These transfer rates can outperform standard Asynchronous 8 and 16-bit Parallel Flash memories" if that means anything to you... :)
I ordered them from this site and all reviews from customers were very good. https://www.aliexpress.us/item/3256804205805912.html

Thanks for looking into it. I am going to build a couple more using pin headers even though that will raise the profile, but it will make it easier to mix and match for testing, and also allow me to switch to the actual Raspberry pi picos later if I have too...

[frntc]

The Winbond flash ICs are ok. Don't remember that other brand, but those were horribly slow. One test you can do before soldering the Pico clone is a) flashing the hello-world-blink program (somewhere on the SDK github), and b) test if the Pico runs the program after every reset. We had some Pico clones where this did not work reliably and there was no obvious reason why. Maybe you were just unlucky with the batch you got :-/

[MarkMccabe]

I would also like to play a bit with the timing settings. I have heard some builders say their experience with the first rev C64 (5 pin video 336298) have had similar issues like popping up with the incompatible timing error message and/or garbled menu. What's really weird is that even with the garbled menu, it appears to play sounds just fine in most cases... I would like to play with the settings a bit...
So to adjust the settings, we use "skpicopatch.exe [FIRMWARE].uf2 15 11 20" (default values shown).
I read the first parameter is the phi2 timing (5-20 are allowable values
I read the second parameter is the buss timing (5-25 allowable)
And the third one is for paddle tweaking to pass the diagnostic tests on some machines.
For the first two parameters I read that "smaller values ​​mean less waiting for reading/writing signals to the bus. Most likely you need to decrease these values ​​if you experience problems with the default timings."
For a non electrical engineer, what does that mean, which is read and which is write, and are we talking the speed the pi accesses the flash memory at or the speed the SIDKick accesses the C64 bus? Please help me understand better using simpler language if that is possible on this technical of an issue. Would a garbled menu but still being able to play sounds be an example of where some tweaking of these parameters would be required or would it not have any effect?
And as always, thanks for taking the time to read and answer these requests from all of us for help.

Finally is there a version of of a blink program (or other pico pi diagnostic "warm fuzzy" program) already in .uf2 format ready for flashing available someplace?

[frntc]

It's all about the C64-bus communication. Many (maybe all) microcontroller-based expansions have a timing relative to the Phi2-clock: "when are signals from the CPU valid on the bus, and when are the data lines set by the CPU valid" (that's the 2nd parameter).

The SKpico can well play sound (maybe with none to only slightly audible glitches) while the menu or transfer of configuration data does not work reliably. The reason simply is that for the latter two the communication over the bus needs to be stable, while wrong SID commands are typically overwritten quickly (most SID players update registers 50x per second).

Here's the blink.uf2: https://www.raspberrypi.com/documentation/microcontrollers/c_sdk.html#blink-an-led