STM32H755 Rev. V RDP Error when erasing flash sectors

MJack.1 · ‎2020-12-18

Hi there,

Our application has a firmware update method that begins by erasing flash bank 2 sector by sector before writing the new firmware.

RDP level is set to 0, but this shouldn't be an issue as we're only erasing a sector.

Occasionally (Maybe 1 in 30 times) when beginning an update, the erase of sector 0 fails. Investigating further, the 'RDPERR' bit of FLASH_CR2 is set. The program continues to run, but the erase will continue to fail until a power-cycle.

I have also previously seen it fail with the 'RDSERR' being set, however we are not using the secure features either.

We have tried for weeks to reliably reproduce this issue, and we can't.

The method we use to start a flash sector erase, after unlocking the flash with HAL:

void eraseSectorBank2(uint32_t Sector)
{
	FLASH->CR2 &= ~(FLASH_CR_PSIZE | FLASH_CR_SNB);
	FLASH->CR2 |= FLASH_VOLTAGE_RANGE_3; 
	FLASH->CR2 |= (FLASH_CR_SER | (Sector << FLASH_CR_SNB_Pos) | FLASH_CR_START);
}

Is there any known issue here, or anything we could have overlooked? I'm pretty confident that our erase / write process is generally correct as it works the other ~29/30 times!!

Many thanks,

Matt

Uwe Bonnes · ‎2020-12-18

Where do you wait for erase complete? First flashing needs to start up VPP generation and may take longer! Also check for flash handling errors and clean up errors found before starting a new flash procedure.

MJack.1 · ‎2020-12-18

Thanks for the reply,

After starting the erase as above, we then periodically check the flash status register, returning 'busy' while any of the queue/wait/busy bits are set, error if any error bits are set, and success if the end of operation bit is set.

We also clear any of these raised error / EOP flags before returning from this update function.

Perhaps we should not be checking the RDP / secure error bits, but I can't see why they should be set.

waclawek.jan · ‎2020-12-18

I have no idea what might be the cause of your problem, but here are some random questions:

> Perhaps we should not be checking the RDP / secure error bits

Do you check them *before* attempting the erase? (Read, if you don't can you plese try it as an experiment, yes, at least 40x)?

Do you perform Standby/Wakeup, and try to erase after that?

Do you perform any reset besides power-up reset (e.g. watchdog, or NRST)? Is the failure related to that other kind of reset?

Is your powerup clean, i.e. isn't there a glitch? Do you use BOR? Do you have an external reset IC handling powerup reset, pulling NRST? Don't you have anything on NRST which would pull it *up* hard?

Do you use the builtin bootloader?

Do you use some of the dual-bank facilities? The erased sectors are in which bank?

Do you change the Option Bytes from program?

JW

MJack.1 · ‎2020-12-22

Thanks for the reply JW!

Do you check them *before* attempting the erase? (Read, if you don't can you plese try it as an experiment, yes, at least 40x)?

Kind of - To help debug this issue we print them out to a debug console before the erase starts, and they always look ok. We don't actually check the flags in the code. I will try checking all of them repeatedly before erasing - I guess something unrelated could be setting them.

Do you perform Standby/Wakeup, and try to erase after that?

No, we don't use any standby / sleep features

Do you perform any reset besides power-up reset (e.g. watchdog, or NRST)? Is the failure related to that other kind of reset?

After a successful update we will call HAL_NVIC_SystemReset() to reboot the device, but this issue can occur after a power cycle without any call to HAL_NVIC_SystemReset().

Is your powerup clean, i.e. isn't there a glitch? Do you use BOR? Do you have an external reset IC handling powerup reset, pulling NRST? Don't you have anything on NRST which would pull it *up* hard?

We have never noticed an issue with the power up, but I haven't looked at the voltage rise on a scope for several months. We do not use BOR, we do have a pullup on NRST. What are your thoughts behind this?

Do you use the builtin bootloader?

No

Do you use some of the dual-bank facilities? The erased sectors are in which bank?

Yes, we do. We boot from 0x08000000, which is referred to as bank 1, even if the banks are swapped. This means that when performing an erase, we always target flash bank 2 registers. I have seen the erase fail when the banks are swapped and when they are not.

Do you change the Option Bytes from program?

Only in two circumstances - We use options bytes to set the M4 boot address on first boot, and we use them to swap flash banks after a successful update.

Many thanks

claymation · ‎2022-02-07

Related post: https://community.st.com/s/question/0D50X0000BaKiDBSQ0/spurious-rdperr-and-rdserr-when-all-protection-and-security-settings-are-off

GLASS · ‎2022-02-07

Hi, few years ago on a stm32l4, à friend got problem with flash erase.

After lot of try we catch that iwdg was partially disabled by only comment MX_IWDG_Init() call in main.

Doing that result in a handle to iwdg that is a nullptr.

On other part of SW the IWDG refresh was not commented, result to unexpected write access @0x00000000 witch is an alias to FLASH 1st bank. It was an unauthorised access made by a RTOS task but was not catched by memfault or hardfault.The next access to Flash, trying to erase sector was allways unsuccesful...

So try to catch unwanted access to @0... may be it can help you...

claymation · ‎2022-02-13

I think the Cortex-M7's prefetch unit is performing speculative instruction fetches to a (partially undocumented) region of system memory (0x1FF0 0000 - 0x1FF7 FFFF) decoded by the flash controller, which sets RDSERR in protest. Mapping this region as Execute-Never with the MPU inhibits the speculative fetch, preventing the RDSERR.