Hello Owen, thanks for your report! I've put the SFDP information (auto detection) from your log together with some details from the datasheet [1] into a patch [2]. There is one oddity, though: SFDP reports slighlty different block erasers compared to the datasheet. I followed the latter for the patch. This means that automatic erasing during write operations could fail. However, the following should work fine: * Reading the whole chip (assuming your connection is reliable; it's best to read once and then verify (`-v`) multiple times to be sure) * Erasing the whole chip (`-E`) and writing afterwards. If you want to experiment with the block erasers, I suggest you make a backup and then try to write some random data with a layout as below (it's important to use different random data on every run so flashprog won't skip anything). Let me know if you need any help. In any case, we can help you to recover from a bad flash as long as you have a backup. Nico $ cat layout.txt 000000:007fff 32k 080000:087fff 32k2 0f8000:0fffff 32k3 000000:00ffff 64k 080000:08ffff 64k2 0f0000:0fffff 64k3 $ flashprog... --layout layout.txt -i 32k -i 32k2 -i 32k3 -w random.bin $ flashprog... --layout layout.txt -i 64k -i 64k2 -i 64k3 -w random2.bin [1] https://ww1.microchip.com/downloads/aemDocuments/documents/MPD/ProductDocume... [2] https://review.sourcearcade.org/c/flashprog/+/263 Using git this can be applied as follows: git fetch https://review.sourcearcade.org/flashprog refs/changes/63/263/1 && git cherry-pick FETCH_HEAD On 18.10.24 14:08, Owen Vogelgesang wrote:

Hello! Was trying to flash a flash chip, and found out it's not in the database. Submitting this information so that it might get added. It's an SST26VF080A, it looks like the larger variants of it are supported but not the 080A. Thanks! Owen Vogelgesang

_______________________________________________ Flashprog mailing list -- flashprog@flashprog.org To unsubscribe send an email to flashprog-leave@flashprog.org