[En-Nut-Discussion] IAP Api proposal, was: Re: nvmem problems with STM32F103

[Uwe Bonnes]

>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:


    Ole> Could you provide me your code as a reference?

Sent in private mail.

...
    Ole> Ok. Does the API provide access to the whole flash or shall it only
    Ole> access the NVMEM area?

The exported API should access all flash _except_ the nvmem area. NVMem is
another API, already implemented in NUTOS. IAP could be used e.g. by a
Bootloader to reflash the user program or replace other data in flash.
My STM32 nvmem implementation internaly uses the IAP functions however...

...
    Ole> Unfortunately the LPC does not support flash protection. Or better
    Ole> said: The flash is automatically protected after write and has to
    Ole> be "prepared" each time you want to write to it.

A similar protection is implemented in STM32. You have to prepare the flash
each time you write. If LPC doesn't provide write protection, the lpc
implementation should return failure when somebody wants to write protect
some code,.

...
    Ole> This should allow access to the whole flash, right? Not only the
    Ole> configured param space?

Again, IAP is for reflashing, nvmem is another thing.

    Ole> How shall it handle a write to an unaligned address (e.g. not a
    Ole> multiple of a sector etc?) And does len must be a multiple of
    Ole> e.g. a sector site?

    Ole> For example the LPC needs the addresses to be 256 byte aligned.

If the implementation doesn't implement a clever scheme to read the old data
and overwrite with the new data, it should return error, or it may be
clever and try to fullfill the request.

...

    Ole> Ok, so you keep a list of erase blocks, right?

Yes. The list is one 32-bit word for F2/4 and up to 48 words for the High
density L1 parts.

    Ole> The LPC does only allow to write 256 | 512 | 1024 | 4096 at
    Ole> once. Single byte writes are not allowed. So a single byte access
    Ole> would need to be simulated.

    Ole> I'm not sure, if modifying a not fully erased page is allowed on
    Ole> the LPC.

Have a look at the programming specification, I guess a single word write
with the complement of the erased data will be possible on LPC. But anyway, the
unit size for the smallest possible erase on the LPC seems sensible, and so
any request can be fullfilled with reading the old data from the unit the
address of the new data points to into a buffer with the unit size, then
overwriting the buffer with the new data, erasing the old unit and writing
buffer into the unit. Being able to overwrite byte/short/word however will
spare erase cycles and so prolong flash lifetime and allow wear leveling.

    Ole> Ok. Do you reserve a full 128K Page for the parameter space on this
    Ole> device?

F2/F4 starts with 4 16k sectors, one 64 k sector and 7 128 k sectors. These
are the smallest erasable units.  One could use e.g. the second 16k sector,
but then code space layout gets complicated. So using the last 128 k is the
KISS approach.

    >> FLASH_ERASE_NEVER I use to mark flash config pages in the 128kiByte
    >> sectors of the F2/4 invalid by writing 0 to top of the page. A config
    >> page of 128 kiByte again would require a 128 kiByte RAM buffer when
    >> erase is needed, so dividing the sector into config pages only needs
    >> resonable sized RAM buffer and allows some wear leveling by copying
    >> the old page to the next page on content cange and invalidating the
    >> old page. Read searches for the first valid page and reads from
    >> there.

    Ole> Ok, but in sum, you need a full flash sector, right?
As a F2/4 sector is the smallest erasable unit, for nvram one full sector is
needed, be it 16/64 or 128 kiByte.

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------