Spurious RDPERR and RDSERR when all protection and security settings are off

[malcolm23]

I have a project running on an STM32H743IIK6. The program periodically tries to write to the last page of FLASH and the HAL fails fairly often. The failure is in the start of HAL_FLASHEx_Erase where it calls FLASH_WaitForLastOperation before beginning the erase operation. The FLASH_WaitForLastOperation fails because it detects either RDSERR2, or RDPERR2 errors in SR2 even though all security and protection settings are disabled.

In order to debug I enabled the FLASH_IRQHandler and enabled interrupts on RDSERR1, RDPERR1, RDSERR2 and RDPERR2. This interrupt is firing every few minutes, and the processor was just running some instructions out of the first flash bank. The instructions are usually just some FreeRTOS task switcher code, but it can be random.

Originally we thought it was related to running the CPU at 480MHz and possibly overheating; but we dropped to 400MHz and the problem has been observed on a virgin processor within 90 seconds of running while the CPU is still quite cold.

Processor:

STM32H743IIK6 Revision V

PLL Settings:

12MHz crystal on HSE

DIVM1 = /3

DIVN1 = x200

DIVP1 = /2

SYSCLK = 400MHz

FLASH Registers at point of failure (when FLASH_IRQHandler is invoked):

ACR = 0x00000002 (Latency=2 - calculated by STM32CubeMX)

CR1 = 0x01800031 (RDSERRIE1 | RDPERRIE1)

SR1 = 0x01010000 (RDSERR1 | EOP1)

OPTSR_CUR = 0x0BC6AAFF (SECURITY=0 | RDP=0xAA=Protection Level 0 - no protection)

PRAR_CUR1 = 0x000000FF (END1=0 | START1=0xFF)

SCAR_CUR1 = 0x000000FF (END1=0 | START1=0xFF)

WPSN_CUR1R = 0x000000FF (WRPSn1=0xFF)

Many thanks,

- Malcolm

[JMans.1]

Hi Malcolm,

Did you make any progress with this - I am seeing similar behaviour on H743IIT6: RDS and RDP errors get set approx every 11 seconds for bank 1 but not bank 2. Code is executing from Bank1 so assume a bad read ocurring somewhere but I haven't been able to spot anything obvious at the point of the error flags being set.

I have worked around the issue by checking and clearing if necessary the RDS and RDP errors prior to any erase/ write operations but would like to understand what is triggering the errors in the first place.

Thanks,

Jon.

[claymation]

Related post: https://community.st.com/s/question/0D53W00000S68I1SAJ/stm32h755-rev-v-rdp-error-when-erasing-flash-sectors

[claymation]

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.

[JMans.1]

Thanks for that, makes some sense.

[heveskar · Accepted solution]

Hi, can you elaborate on this please?

I think that for STM32H72xxx/H73xxx, the System Memory region 0x1FF0 0000 - 0x1FF1 FFFF contains the ST bootloader (which we are using), so it seems unwise to me to set this region as Execute-Never as you suggest.

As for the rest of the memory (from 0x1FF2 0000 to 1xFFFF FFFF, which seems to be Reserved), is it really needed to set is as Execure-Never in order for flash controller not to try to fetch data from this region?

I am seeking more info as we are using EEPROM emulation on the flash and it has been very unreliable for us. Problem seems to be that sometimes, write accesses to flash fail, which causes ECC errors and we are losing our configuration - some bytes cannot be read anymore and reading them causes hardfault. Only solution we have come with is to erase the whole emulation region then. During last months, several units came back from customers with those issues, so we are trying to make the flash writes more reliable.

Except the other thread you are linking, I would also like to mention https://community.st.com/s/question/0D53W00001lSnKjSAK/flash-ecc-codes-cause-bus-fault-on-stm32h743, which helped me too. I am now doing this:

• Clearing RDS and RDP errors prior to any flash write
• Setting correct value to WRHIGHFREQ as STM HAL seems not to do that correctly

Also @F.Belaid​, what do you think of this?

Karel