Figure out how to unbrick an FPGA with "VLD down!" status about monocle-micropython HOT 7 CLOSED

This seems to happen right after programming.

The LVD status flag goes down, suggesting damage to the flash, but the GOWIN programmer does not seem to dare programming at all anymore after this.

I will try:

• with the FTDI-based programmer
• maybe to reach GOWIN about this?
• use the external flash
• as a last resort, desolder/resolder the chip from a board with a broken ram, to a working board with a "VLD down!" FPGA.

from monocle-micropython.

I am not sure the internal flash is accessible from our system anyway... might only be programmable from JTAG.

We could have emFlash as a factory default with exFlash for user-programming?

from monocle-micropython.

External flash is a good fallback, as we’ll need this anyway. You have only one board currently I suppose?

from monocle-micropython.

I have 4 boards.

• One was shipped with a cracked SRAM die, I think due to the transporter.
• The two MK12 could be flashed a few times, but quickly ended-up with that issue.
• The MK11 could serve its job for long, but finally ended-up with that issue as well.

from monocle-micropython.

Reading GOWIN's datasheet again:

During configuring SRAM devices via built-in Flash (AUTOBOOT configuration and
DUALBOOT configuration) and programming built-in Flash, the FPGA needs to remain
powered up, and the RECONFIG_N cannot be triggered at low level; otherwise, it may
cause irreparable damages to the built-in Flash.

-- https://cdn.gowinsemi.com.cn/UG290E.pdf#page=33

I remember that the MK12 had multiple resets happening (RECONFIG_N pulse as part of reboot loop) happening during verification step, not during programming step.

The MK11 worked reliably until now, and started to fail getting programmed increasingly more often: verification failed at different offset.

The GOWIN Programmer does not allow to flash to SRAM.

The openFPGALoader likely does not check, and keeps programming without checking the VLD signal.

from monocle-micropython.

What I could learn from GOWIN, is whether "VLD down!" means a damaged FLASH chip (and I would then seek what, in what I did, could have damanged it, eventually wearing it off by repeated writes), or something else (bad power rails making the flash unhappy, etc.).

from monocle-micropython.

Internal flash seems like a risky route then 🤔 resets might happen while users are downloading fpga updates, and then it could cause an issue. What if we take this route:

• switch to using external flash for booting
• In parallel confirm the issue with Gowin
• Document the internal flash issue for advanced users who might want to use it in their own custom applications

from monocle-micropython.