[En-Nut-Discussion] IAP Api proposal, was: Re: nvmem problems with STM32F103
ole.reinhardt at embedded-it.de
Fri Jul 19 21:29:45 CEST 2013
> 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.
> * 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
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
kernel concepts GmbH Tel: +49-271-771091-14
Sieghuetter Hauptweg 48 Mob: +49-177-7420433
More information about the En-Nut-Discussion