get_page_size return wrong thing on stm32f4

[LiyouZhou]

The new stm32f4 hal implementation enables programming byte by byte.

Users of FlashIAP usually get the minimum programming size by calling flash.get_page_size(). However in the new stm32f4 implementation returns the "sector size" when get_page_size() is called which is erroneous and prevents effective use of the FlashIAP API.

https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32F4/flash_api.c#L133

@jeromecoutant
@adustm

[LMESTM]

@LiyouZhou thanks for reporting this. I agree that flash in F4 devices can be programmed 1 byte at a time so probably this flash_get_page_size should in the end return 1. Nevertheless the definition of flash_get_page_size does not clearly specify that flash_get_page_size should return the "minimum programing size" - that would help to define it this way.

/** Get page size
 *
 * @param obj The flash object
 * @return The size of a page
 */
uint32_t flash_get_page_size(const flash_t *obj);

[LiyouZhou]

I do agree that the word PAGE is ambiguous and there is no documentation on mbed os to clarify this point. @0xc0170 May shed some light as to the definition of a page?

[LMESTM]

@LiyouZhou , I created PR #4980 to update page size on STM32 targets - maybe can you verify that this improves memory usage as expected

[0xc0170]

@LiyouZhou thanks for reporting this. I agree that flash in F4 devices can be programmed 1 byte at a time so probably this flash_get_page_size should in the end return 1. Nevertheless the definition of flash_get_page_size does not clearly specify that flash_get_page_size should return the "minimum programing size" - that would help to define it this way.

I do agree that the word PAGE is ambiguous and there is no documentation on mbed os to clarify this point. @0xc0170 May shed some light as to the definition of a page?

Let's fix this

[LMESTM]

@LiyouZhou #4980 has been merged and should solve this issue - please confirm and close or report otherwise

[LMESTM]

@LiyouZhou @0xc0170
#4980 has been merged and #4972 is now closed - I think this issue can be closed as well