2018-03-23 08:34 AM
Device STM32L452RE on my HW board with 3V3 Vdd ...
This code is placed in RAM ...
//--- Program
__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_ALL_ERRORS);
//--- FLASH_Program_Fast
uint8_t
ID;
uint32_t
DstAddr = (FLASH_BASE + Addr) & 0xFFFFFFF8;
SET_BIT(FLASH->
CR
, FLASH_CR_FSTPG);
//--- Program the double word of the row
for
(ID = 0; ID < (32 * 2); ID++)
{
*(
uint32_t*)(DstAddr) = 0xAABBCCDD;
DstAddr += 4;
}
// Wait for last operation to be completed
while
(READ_BIT(FLASH->
SR
, FLASH_FLAG_BSY)) {};
if
(READ_BIT(FLASH->
SR
, FLASH_FLAG_PGAERR)) LED_BO_Set(
LED_BO_ORANGE, 1);
Where is error?
#stm32l4-fastprogram2018-04-13 05:57 AM
2. Yes, page erased (
Checked via STM32 ST-LINK Utility v4.1.0.0)
Did you do only a *PAGE* erase? The RM explicitly says that a bank *MASS* erase ist required:
1. Perform a mass erase of the bank to program. If not, PGSERR is set.
...
PGSERR is set if one of the following conditions occurs:
...
In the fast programming sequence: the Mass erase is not performed before setting
FSTPG bit.2018-04-13 07:24 AM
My routine returned PGAERR, not PGSERR ....
I resolved using NormalProgram instead of FastProgram ...
2018-04-13 11:33 AM
The STM32L452 only has one flash bank. That means a mass erase will erase the entire flash memory. And it can't be used to erase part of that memory by write protecting a section of it (for example where a custom bootloader lives), because the RM says 'If the Flash memory contains a write-protected area (by WRP or PCROP), WRPERR is set
and the mass erase request is aborted.'So if FSTPG can only be used after a mass erase, and mass erase must erase every single word in the entire flash, then it seems this is a virtually useless 'feature'. Who in their right mind would build a commercial product that contains an MPU which is going to erase it's entire flash memory out in the field somewhere?
A large number of products being designed these days need the ability to be upgraded in the field. This is done by having some portion of the flash contain a custom bootloader, and some method of handing it a new application to be installed in the rest of flash. You never delete the bootloader. If an update failed at the time when the bootloader (and the rest of flash) was erased, the product becomes a brick. As long as the bootloader survives, then you can always try upgrading again and again. So no rational designer would create a bootloader that erases itself as part of the upgrade process.
If this mass erase requirement is really true, then I have lost a certain amount of respect for ST at this moment.
2018-04-14 08:15 AM
The standard programming does precisely what you want to accomplish. Maybe one should read 'fast programming' in fact as 'production line programming' instead and the RM should clearly state that. (Like the possibility to supply an external programming voltage for faster programming present in some other stm32 variants.)
2018-12-18 10:01 PM
See DataSheet..
from STM32L475:
time for prog dw = 0.08169ms
time for prog row = 32*dw = 2.61ms (1.91ms for fast programming)
You really still need fast programming?!! It's LESS THEN half-page(64byte) programming on STM32L0!
2020-04-01 04:20 AM
Any solution on this? I have the exact same issue for STM32G474.
Code is executing entirely from RAM. It seems there's something essential missing for fast programming.
2020-07-15 02:08 AM
This helped a lot after spending some time trying to debug why PAGE erase (instead of MASS erase) doesn't work with fast programming...
I personally think it should be stated somewhere in the Doxygen comments that come with the code.
Update:
It's section 3.3.7 in RM0432, Rev 4 for those who are insterested.