Unable to write to microchip SST26VF064B

[moffel]

openFPGALoader -c gatemate_pgm --verify -f .\bitfile.bit
empty
write to flash
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
Detected: microchip SST26VF064B 128 sectors size: 64Mb
Erasing: [==================================================] 100.00%
Done
Writing: [==================================================] 100.00%
Done
Verifying write (May take time)
Read flash : [==================================================] 100.00%
Fail
Verification failed at 0

Reading back the flash reveals that it is completely empty.

This might be related to the fact that this chip requires a global unlock after power up before any write. The global unlock is implemented for the 32Mb version of this flash at spiFlash.cpp:360 if (_jedec_id == 0xbf2642bf) { // microchip SST26VF032B but seems to be missing for the 64Mb version.

The requirement to isse a global unlock before any write should probably be a flash property in spiFlashdb.hpp.

In addition it would be nice to add a flag or resuse --unprotect-flash to also issue the global protect unlock command. This command is actually not microchip specific and can be found on winbound chips as well. (W25Q128JV)

It would be great if we could have some very low level spi command issuing flags to diagnose problems like this one.

[trabucayre]

the hack for microchip SST26VF032B was added when I have observed this behavior with alchitry au board but it's true this must be improved with a flag in spiFlashdb header to avoid a too complex test here.
Low level diagnose may be a more harded since it's needs to know specificities for each flash.

[trabucayre]

I have pushed a first commit to handled global_lock via spiFlashdb entries. for SST26 this unlock is always mandatory.
Remaining part is to check the bit for all Flash chip with this feature to decide if it's required to unlock in parallel to the classic approach.

[moffel]

Great — the change looks promising. Unfortunately, I'm currently unable to build openFPGALoader natively on Windows and I'm not very familiar with MSYS.

Would there be interest in making the code more portable, so that it can compile on Windows and other platforms more easily?

I took a quick look at the build errors, and it seems that the main issue is the use of modern C features that aren't compatible with standard C++. In particular, variable-length arrays on the stack appear to be a problem.

If there's interest in improving portability by aligning with standard C++ practices, I'd be happy to spend some time replacing those constructs with equivalent C++ alternatives.

[trabucayre]

Have you some link to documentation on how to build an application natively? I have already built openFPGALoader with MSYS or WSL. I'm interested to see errors because openFPGALoader build successfully on Linux, MacOS, MSYS and WSL.

[moffel]

On Windows I would suggest to install the free Visual Studio 2022 Community edition and use the "open folder feature". It will detect the cmake project automatically. For dependencies, the most common and hassle free solution is to use vcpkg. https://github.com/microsoft/vcpkg

It currently does build on all those platforms because you are using the same compiler on all of those. Clang also tries to be as close as possible to gcc, but that doesn't mean its standard or portable. Using gcc on Windows would also be possible and does not require changing the non standard parts.

I cannot see a lot of platform depended issues in the code base, it is really more about usage of non C++ features.

[trabucayre]

It's possible with cmake on Linux to specify compiler.
with clang and -DCMAKE_BUILD_TYPE=Debug I observe lot of -Wvla-cxx-extension due to arrays with an unknown size at build time.
Will try to see how to convert it to something acceptable by clang but I also needs to evaluate cost (time) to std::array for example.