cancel
Showing results for 
Search instead for 
Did you mean: 

FLASH FastProgram allways return PGAERR ...

varga
Associate II
Posted on March 23, 2018 at 16:34

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-fastprogram
16 REPLIES 16
Posted on April 13, 2018 at 12:57

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.
Posted on April 13, 2018 at 14:24

My routine returned PGAERR, not PGSERR ....

I resolved using NormalProgram instead of FastProgram ...

Posted on April 13, 2018 at 18:33

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.

Posted on April 14, 2018 at 15:15

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

VC.8
Associate

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!

jr
Associate II

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.

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.