Support separate flash erase and write page sizes

[flit]

Some flash memories, such as QSPI, have different erase and write block sizes, with the erase block size being larger than the write block size. Most MCU internal flash controllers allow programming granularity of somewhere between 1 and 16 bytes (depends on flash technology and controller IP). But some flash technologies, particularly smaller geometries and external flash memories, have much larger minimum write sizes such as 512 bytes. Current flash algos have always handled this by simply accepting multiple blocks to write in the ProgramPage() API, which fit well with the 1-16 byte write granularity. However, not all flash algos work this way..

In addition, some targets, notably some STM32 devices, have crazy large erase sector sizes (up to 128 kB!). This can prevent double buffering from being enabled since there is not enough RAM to fit two of these sectors. The solution is to support a flash write page size that is smaller than the sector size. The main constraint is that you want to have as large programming buffers as possible to reduce buffer swap and command issuing latency.

[stppgit]

This also impacts external memory programming using QSPI interface in Cypress PSoC 6 devices.
S25FL512S memory, for example, has erase page == 256K, what requires 256K of PSoC 6 SRAM to be allocated as the data buffer. Algorithms data + stack also requires up to 32Kbytes of SRAM.

This tightly works for PSoC6A-BLE2 devices with 288 Kbytes of SRAM but does not work for PSoC6 devices with SRAM size < 288KBytes and for secure devices where SRAM access is limited to specific regions.
In addition, we cannot use double-buffering to speed-up programming, what is critical for large QSPI memory devices such as S25FL512S (64M).

[flit]

Exactly right. Please see my feature/flash_erase_program_size branch. It's mostly done, except that the flash_test.py functional test fails. This is most likely due to assumptions the test makes that are no longer valid, rather than real bugs, but of course it must be fixed before the branch can be merged.

[stppgit]

Sounds promising. Waiting for mainline intervention. Thanks a lot Chris!