This has been discussed here several times, e.g. here and here.
> What kind of FLASH memory is embedded into the STM32U5 (NOR or NAND) ?
It doesn't matter, as it's the behaviour which matters, not the moniker.
Besides, the basic physical principle (i.e. floating gate) is identical for both, and thus the basic wear mechanisms are identical, too.
> What is the reason for the wearing of FLASH ? Is it writing into the FLASH or is it erasing it (mass erase or page erase) ? For instance, does writing only 0 into the flash wear it ?
Both writing and erasing. The datasheet number is usually given for write-erase cycle. There may be multiple writes to different portions of a page, if the given FLASH allows it (and in STM32 FLASH, it does, as the write granule is quad-word).
Besides individual pages having a cycle limit, there is also a cumulative cycle limit for the whole FLASH (or a bank), due to wear of the HV sources/switches needed for the FLASH operations. This is probably the reason for the "only 32 pages per bank may be cycled up to 100k" limit.
There are also secondary issues like crosstalk between neighbouring rows, which gets worse with increasing number of cycles.
> What is ST's recommended way to deal with flash wearing ?
Don't wear it beyond what's specified. How do you achieve that, it's up to you and the application.
In some applications, for example, it may be perfectly OK to maintain a counter in one word of the cycled page, and when this counter reaches the limit, the product simply stops working. You'd consider this to be outrageous for most applications, but there are applications out there where this is perfectly OK.
A common strategy is to reduce cycles per change, e.g. you won't erase the whole page and then write a single value, but design some journaling method to allow multiple writes of the same "variable" into a page. Using multiple pages is another strategy to reduce wear on individual page. Another strategy is to have a backup power source - usually a large enough capacitor - to extend runtime beyond primary power failure (suitably monitored), to allow writeback from RAM cache to FLASH/EEPROM.
There are too many options for one library to be reasonably effective for all of them, so in most of the cases it's more reasonable to write your own solution tailor-fit to your application.
There may be also no solution for you within the constraints given by FLASH endurance and your application's requirements. In that case you may want to consider different physical approach, e.g. using battery backup (all STM32 have a couple of battery-backup registers in RTC/TAMP; some STM32 do have battery-backup RAM - not the 'U5 but you there may consider using some of the ultralow-power modes which support RAM retention); or fast high-cycle nonvolatile memories like FRAM or MRAM.
> How does one tell the flash controller to configure a page do be cycled up to 100k cycles rather than 10k?
You don't. The specifaction is, that you may wear *any* page beyond 10k, but only 32 pages per bank. So you choose, which pages are you going to wear significantly (i.e. use in EEPROM-like role), but only can choose only 32 pages to do so.
Also note, that once you wear a page beyond 10k, a different max programming/erasing timing applies for that page (see datasheet). While from this fact it may appear that there's some abrupt change at 10k (which would imply an embedded counter), no, that's simply that the programming/erasing times increase with wear and ST gives an upper bound to them based on testing.
JW
