Yes, you can damage flash memory

I have been writing a driver and hooking up LittleFs to an external SPI connected flash memory, W25Q32BV from Winbond with 32Mbit of memory with 1024 erasable sectors. It worked well, I could write and read data and the file system was working just fine.

At one point when adding QSPI commands I noticed the file system begun having problems. One deep dive later I realized that reading from certain sectors often (but not always) returned the MSB as 1 while I was expecting 0. In my case the problematic sectors started at sector 512 and ended at 768 (evenly divisible by 256). I took this as a hint that I somehow handle addressing incorrectly, and kept debugging the code for a while longer.

Comment                         Sector start address
Sector 0 write success          00000000 00000000 00000000
...
Sector 511 write success        00011111 11110000 00000000
Sector 512 write failed         00100000 00000000 00000000
Sector 767 write failed         00101111 11110000 00000000
Sector 768 write success        00110000 00000000 00000000
...
Sector 1023 write success       00111111 11110000 00000000

I could not find anything wrong in the code, and after busting out the oscilloscope I could see that it agrees with the readout of 0x80 where I was expecting a stored 0x00 byte.

The oscilloscope readout indicated that something was probably wrong with the flash chip itself, or that I had some timings wrong in the protocol configuration.

I bit the bullet and switched out the flash memory, after that the low level tests work just fine again and LittleFs file system is up and running with QSPI commands making it faster.

My lesson was to always consider broken hardware and not get too stuck on the possibility of a software issue until the hardware has been confirmed to work properly.