gowin: fix GW5A external flash writes being erased by hardware auto-erase#644
Open
key2 wants to merge 2 commits into
Open
gowin: fix GW5A external flash writes being erased by hardware auto-erase#644key2 wants to merge 2 commits into
key2 wants to merge 2 commits into
Conversation
…rase The Reinit command (0x3F) sent in gw5a_enable_spi() triggers a hardware-initiated bulk erase of the external SPI flash (status register bit 31 'auto_erase'). The code previously proceeded immediately to flash programming, creating a race condition where the ongoing background erase would corrupt or wipe written data. Fix by polling the status register after Reinit until the auto_erase bit clears before continuing with SPI bridge setup and flash operations. Also reset the SPI flash chip in programExtFlash() before releasing the JTAG-SPI bridge, ensuring the flash is in standard SPI mode for the hardware boot loader. Tested on GW5AT-15 (idcode 0x0001681b) with XTX XT25F128B flash.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
auto_erase(status bit 31) to complete after Reinit (0x3F) ingw5a_enable_spi(), preventing a race condition where flash writes get wiped by an ongoing hardware-initiated bulk eraseProblem
On GW5A/GW5AT devices with external SPI flash,
--write-flashappeared to succeed (including--verify), but after a power cycle the new firmware was never loaded. The FPGA status register showedauto_boot_1st_failandauto_boot_2nd_fail.Root Cause
The
gw5a_enable_spi()function sends the Reinit command (0x3F) which triggers a hardware-initiated bulk erase of the external SPI flash (visible as status register bit 31auto_erase = 1). The code previously proceeded immediately to SPI bridge setup and flash programming without waiting for this erase to complete. This created a race condition: flash writes appeared successful through the JTAG-SPI bridge but the ongoing background auto-erase would corrupt or wipe the data.Testing
Tested on GW5AT-15 (idcode
0x0001681b) with XTX XT25F128B (JEDEC0x0B4018) external SPI flash via ft4232 JTAG cable. Write + verify succeeds and flash data persists across multiple operations.