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

  1. Put a broken-hyperram core onto slot 1 (e.g. build 201)

  2. power-up, wait slightly less than 1 second and then hold down NO-SCROLL

  3. 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

  4. Press CTRL-1 to flash slot 1

  5. When this fails and goes into the flash-inspector (hexdump output), press RUN-STOP to get back to the flashing-loop

  6. 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)

Â