UnlockedFlash: support PSIZE_X32

[sre]

ST Refernce Manual RM0090 suggests using PSIZE_X64 when external Vpp is applied, PSIZE_X32 when voltage is between 2.7V and 3.6V, PSIZE_X16 when voltage is between 2.1V and 2.7V and PSIZE_X8 is between 1.8V and 2.1V. UnlockedFlash currently only supports PSIZE_X8.

Since 3.3V is a common voltage and writing 32bits instead of 8bits speeds up things a lot, I would like to see support for it.

[burrbull]

Does it mean program/read should take u32 instead of u8, or does not?

[sre]

Ideally the program/read API stays the same I guess. I have not yet looked into how to implement this best. I noticed that the flashing of 64KiB takes roughly 40 seconds instead of 10 seconds compared to the built-in bootloader. Looking for the root cause I noticed this issue. Datasheet information about flashing looks like this (I trimmed it a bit):

The Parallelism size is configured through the PSIZE field in the FLASH_CR register. It represents the number of bytes to be programmed each time a write operation occurs to the Flash memory.

	2.7V - 3.6V + Vpp	2.7V - 3.6V	2.1V - 2.7V	1.8V - 2.1V
parallelism	x64	x32	x16	x8
PSIZE	0b11	0b10	0b01	0b00

Note: Any program or erase operation started with inconsistent program parallelism/voltage range settings may lead to unpredicted results. Even if a subsequent read operation indicates that the logical value was effectively written to the memory, this value may not be retained.

[burrbull]

Should something like https://github.com/stm32-rs/stm32f4xx-hal/commit/fff9621ad031fbea5b6cdabb1e33a790e9d52bfc be enough?

[sre]

I gave that a try and it's not enough. Using that with X8 works. For X16/X32 erasing works (and is faster), but unlocked.program() fails.

Looks like https://github.com/stm32-rs/stm32f4xx-hal/blob/fff9621ad031fbea5b6cdabb1e33a790e9d52bfc/src/flash.rs#L262 needs to write 16 bit / 32 bit / 64 bit instead of 8 bit when PSIZE is configured to X16/X32/X64.

[burrbull]

needs to write 16 bit / 32 bit / 64 bit instead of 8 bit when PSIZE is configured to X16/X32/X64.

This is what I asked about.

~~FlashExt should have <Word> generic instead of just u8~~. Also all start/end operation addresses are needed to be checked.

P.S. Also different chips have different sector map that looks missed in current implementation.

[sre]

I think ideally the program() function takes u8 and internally does a 0-3 single byte writes to reach 32 bit alignment, then does 32 bit writes and finally uses 8 bit writes again for the last 0-3 bytes.