flash sector erase fails on stm32f412

[StefJar]

I running my zephyr based firmware. Before it is run a boot loader selects the firmware image. This bootloader sets the FLASH_OPTCR register. All sectors are disabled for writing(erasing).

using flash_write_protection_set function doesn't fail when enabling writing - but after flash_erase fails because of the FLASH_OPTCR bootloader preset.

The current problem with the stm32 flash driver is, that it assumes that its runs after a reset.

I done a fix for the stm32f4xxx code. It's below:

iff --git a/drivers/flash/flash_stm32.c b/drivers/flash/flash_stm32.c
index fe50b88e8e..400b0c1255 100644
--- a/drivers/flash/flash_stm32.c
+++ b/drivers/flash/flash_stm32.c
@@ -329,6 +329,27 @@ static int stm32_flash_init(struct device *dev)
        LL_AHB3_GRP1_EnableClock(LL_AHB3_GRP1_PERIPH_HSEM);
 #endif /* CONFIG_SOC_SERIES_STM32WBX */
 
+#if defined(CONFIG_SOC_SERIES_STM32F4X)
+       // make sure that user options are disabled
+       // they affecting if flash read/write operations
+       // are allowed on the flash for spezific sectors
+       struct stm32f4x_flash *regs = FLASH_STM32_REGS(dev);
+
+       // check if we are not in the typical rest config
+       if (regs->optcr!=0x0FFFFFED) {
+               // clear OPTLOCK
+               regs->optkeyr=0x08192A3B;
+               regs->optkeyr=0x4C5D6E7F;
+               if (regs->optkeyr & 1) {
+                       // still locked
+                       // we failed
+                       return -EIO;
+               }
+               // now write rest config
+               regs->optcr=0x0FFFFFED;
+       }
+#endif
+
        k_sem_init(&p->sem, 1, 1);
 
        return flash_stm32_write_protection(dev, false);

Think all the other stm32 flash driver implementations may need some attention.

[ioannisg]

@erwango could you take over this, or re-assign if needed?

[ioannisg]

@StefJar could you send up a PR if you already have a fix for that?

[StefJar]

This fix only addresses the stm32f4 part of the stm32 flash driver. Think @erwango needs to check the other stm MCUs.

[erwango]

@StefJar, well is that a bug actually? This should rather be an enhancement.
STM32 flash driver doesn't handle flash option control register. If your bootloader modifies it, well, it won't work indeed, but this is true for lot of other option bytes that are not handled by driver.

[lucaspeixotot]

@StefJar the bootloader that you are using is the mcuboot? I'm having a similar problem when I swap images between slot0 and slot1 with mcuboot. My board is nucleo_f091rc. My error is a HARD FAULT like the one below:

***** HARD FAULT *****
***** Hardware exception *****
Current thread ID = 0x00000000
Faulting instruction address = 0xfffffffe

I realized that my problem is when the mcuboot calls the flash_write_protection_set function that is inside both flash_area_erase and flash_area_write functions.

I created a blank project with these statements in the main and I didn't get errors.

u8_t buff[] = "aaaaaaa";
int err            = flash_area_open(SCRATCH_ID, &fap);
if (!err) {
    printk("scratch -> fa_off: %X, fa_size: %X, fa_id: %d, fa_device_id: %d\n", fap->fa_off,
           fap->fa_size, fap->fa_id, fap->fa_device_id);
}
err = flash_area_write(fap, 0, buff, strlen(buff));
if (err) {
    printk("Error writing...\n");
} 
err = flash_area_erase(fap, 0, fap->fa_size);
if (err) {
    printk("Error erasing...\n");
}

So I realized that the problem is just when I'm trying to manipulate(write/erase) flash in the mcuboot project. If you are using mcuboot, where it is setting the FLASH_OPTCR register? Maybe something similar is happening to me.

[rljordan-zz]

Priority?

[StefJar]

@lucaspeixotot I don't use mcuboot. I have a "beautiful" in company written legacy bootloader that I need to deal with.
I didn't check MCUboot, but I guess it has a flash driver as well. Maybe you need to patch this driver. Check f091 datasheet. I am not sure, if my f412 solution works for that.

[lucaspeixotot]

@lucaspeixotot I don't use mcuboot. I have a "beautiful" in company written legacy bootloader that I need to deal with.
I didn't check MCUboot, but I guess it has a flash driver as well. Maybe you need to patch this driver. Check f091 datasheet. I am not sure, if my f412 solution works for that.

I think that my problem is different. Today I realized that the hard fault occurs when the semaphore in flash_write_protection_set function is being given. What is curious is that this driver works properly in other projects than are not mcuboot.

[erwango]

Since optcr is not supported (so not modified) within zephyr driver, there is no bug here but a compatibility issue with an eternal component.
Moving this as an enhancement rather than a bug.

[erwango]

Looking to it more in detail, I don't think requested modification would even be an enhancement that would be acceptable in flash driver.
Option bytes are meant to configure behavior persistant across reset. Resetting them blindly at boot in application is a quite particular usage.
If bootloader configures option bytes in a way that is incompatible with the application usage, it rather seems as a bug in the bootloader than a feature we want to support in application flash driver.

[StefJar]

after discussing it with @erwango we decided to close this issue. Key points for not merging the proposed commit workaround to the stm32 flash driver:
1st) this code only works for STM32F412
2nd) it sets blindly the flash OPTCR register to reset mode. Maybe this is not wanted.
3rd) we leave it to the user to know from which context his zephyr image is run. So the user needs to take care of this register.

I put the code to a git repro. so everyone can use this as a blueprint for similar problems.

https://github.com/StefJar/zephyr_stm32_flashOPTCRreset

[mtahirbutt]

Hi @erwango and @StefJar, I am facing a similary problem with my disco_l475_iot1 board which has stm32l475 MCU. I am using mcuboot for updatehub app. flash_write_protection_set works fine but flash_erase() is not successful. I checked carefully all the partition sizes they are perfectly according to DTS file. Now I tried to see OPTCR register but could not find it. could you please suggest a workout or solution to this issue.

thanks

Tahir

[erwango]

@mtahirbutt, please raise a new issue and explain your problem.
One thing you can do is test your erase command on flash_shell sample (if issue is not linked to partitioning).

[mtahirbutt]

Hi @erwango, I tried flash_shell command and tried to erase partitions. it returns here with -5 again. similar problem as that with updatehub.