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

[Ole Reinhardt]

Hi Uwe,

> I have code for nvmem with flash on F1/3/ and  F2/4 and on EEPROM L1 in
> private trunk. The code automatically reserves FLASH_CONF_SIZE when
> configured at the end of flash when working with flash. No need to configure
> the config location, only eventually the size/

Could you provide me your code as a reference?

> It uses an In-Application-Programming API I would propose for EN-Nut and I
> have implemented for F1/3, L1 and F2/4/

What do you mean with IAP API? AFAIK a flash API to control the STM32
flash controller yet exists as stm32f1_flash.c? Does it use this file?

> The API requires the application code to have as minimal knowledge of
> the actual flash layout as possible, so application code is as portable as
> possible. It consists of

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

> * uint32_t IapFlashEnd(void);
> to return the end of Flash, excluding eventual configured configuration space.

Ok.

> * FLASH_Status IapFlashWriteProtect(void *dst, size_t len, int ena);
> to change write protection of the specified range, extending the
> range to physical units of flash the architecture can protect.

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

> * FLASH_Status  IapFlashWrite( void* dst, void* src, size_t len,
>   FLASH_ERASE_MODE mode);
> to write the provided space with the provided data. If src == NULL, only a
>   check for write protection is done. Configuration space is excluded in the
>   exported API.

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

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

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


> ** FLASH_ERASE_MODE may be
> - FLASH_ERASE_ALWAYS where the minimal physical flash unit including the
>   requested area is _always_ erased before writing
> - FLASH_ERASE_NEVER where no erase is done before writing. Writing will
>   succeed if flash was erased before, for many architecture if the pattern
>   written is the complement of the erased flash pattern and may also
>   fail when not working on erased memory. User has to know what he does and
>   must check return value.
> - FLASH_ERASE_FIRST_TOUCH where NUTOS keeps track of the sectors it has
>   erased. If a write request to the pysical flash unit is requested, erase
>   is done and the sector erased. Later write requests will not erase.
>   Writing a single 32-bit word at a 32-bit boundary should always succeed on
>   erased flash, writing smaller units off the boundary may or may not
>   succeed, depending on implementation and architecture. E.g. F2/4 allows Byte
>   write for the flash, and L1 has small 256 byte pages where we can load the
>   old page content and only substitute the new data. So Byte write is
>   possible. On F1/3, only 16-bit write at 16-bit boundary is possible and
>   sectors are quite large with 2048 byte, so byte write will fail.

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

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

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

> * void FlashUntouch(void)
> will zero out the list of already erased physical flash units.
> 
> Why do we need FLASH_ERASE_FIRST_TOUCH?
> E.g. STM32F4 has flash sector sizes of 128 kiByte. For In-appplication
> programming it will nearly be impossible to provide a 128 kiByte RAM buffer to
> assemble a full sector before writing. With FLASH_ERASE_FIRST_TOUCH we can
> write smaller chunks.

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

> 
> 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.

Ok, but in sum, you need a full flash sector, right?

> Ole, you already have some IAP routines for NXP. Would you consider
> exporting above API?

Yes I can try. But I like to have a look into your code to be sure I
fully understood it.

Could you please also provide me the code that uses this API? e.g. the
NVMEM code?

Bye,

Ole

-- 
kernel concepts GmbH            Tel: +49-271-771091-14
Sieghuetter Hauptweg 48         Mob: +49-177-7420433
D-57072 Siegen
http://www.embedded-it.de
http://www.kernelconcepts.de