QSPI issue

A page to document details of users affected by the QSPI issue:

User	QSPI dump	Notes

User	QSPI dump	Notes
MC64	mc64_qspi.bin	Experienced on r3a board Was able to temporarily upload bitstream via m65 (+winusb drivers via zadig tool), but seem unable to re-program qspi (tried with jtagflash, no luck)
Alexco		.cor manually copied to sdcard. Used external sdcard slot. Possibly pressed NO-SCROLL late (and entered slot 1’s megaflash util)
gurce	gurce_qspi.bin	Tried to replicate on devkit by putting broken 201 build on slot 1 then pressing NO-SCROLL late. My symptoms match what others experienced, but this only corrupted my slot 1 (not slot 0)

Gurce’s steps to potentially replicate

Put a broken-hyperram core onto slot 1 (e.g. build 201)
power-up, wait slightly less than 1 second and then hold down NO-SCROLL
Via serial terminal/m65dbg, type ? to assure that core-slot menu program that appears belongs to slot 1
- If not, go back to step 2 and try again, adjusting the timing of when you hold NO-SCROLL slightly
Press CTRL-1 to flash slot 1
When this fails and goes into the flash-inspector (hexdump output), press RUN-STOP to get back to the flashing-loop
This will then attempt to flash from sector $0 onwards (possibly trashing slot 0)

Gurce’s set of screenshots when attempting to replicate

Note: If you experience symptoms like this, please try remember to take screenshots at every step you can too!

I press space and get this:

I press space again and get:

I then power-off and on again, to see this:

(note: affected users aren’t lucky enough to see this, as it is a message that a working slot 0 provides)

Pressing space takes me to my megaflash core menu, albeit with a borked slot 1:
(again, for affected users, they won’t be as lucky, as their slot 0 is borked instead)