[STM32WB55] Flash operations without Wireless Stack and without using CPU2

[Sander_UP]

Hello!

I have a question about doing flash operations without the BLE wireless stack firmware being present in STM32. As it seems from the examples, the flash operations requires to notify the CPU2. For example, when doing flash erase, the CPU2 will have to be notified first in order to continue with it. But since wireless stack is not present, a HardFault is encountered after notifying, because no wireless stack is present. The question is now, if it is possible to do flash operations without having to notify CPU2, and thus not needing to have the wireless stack present in STM32?

If the answer is yes, then where could one find an example of doing so?

[Lubos KOUDELKA]

Hello,
flash algorithms from AN5289 are expecting wireless stack is loaded and running. When stack is not running (not even loaded), there is no need to protect timing or prevent conflicts between CPUs and regular flash access like on other single core STM32 can be done.

Example FLASH_EraseProgram is applicable in such case.

Best regards,
Lubos

[Sander_UP]

Hello!

@Lubos KOUDELKAthank You for the answer. As soon as I am able to test the flash operation with the example provided on the STM32, I will let You know how it went.

Edit: As I remember that I had tested the flash operations by removing everything related to CPU2. But since it was a couple of weeks ago, I do not exactly remember what went wrong then. But anyways, rechecking the software with the example given I will do more testing and will write the results here once I get back.

All the best,

Sander

[Sander_UP]

Hello!

Been busy these three weeks, but this week finally had the chance to test it again.

Tried to rewrite the code like in the example provided by Lubos, but to no avail. Unlocking the flash to do a page erase can be done, but when trying to lock the flash again, then a Hard fault occurs. The problem there is that it tries to lock the flash by setting FLASH_CR_LOCK bit to 1, but this does not apply. After that the program immediately checks if the process was a success, and at that point the Hard fault occurs. This is where the Hard fault kicks in:

 

 

/* verify Flash is locked */
 if (READ_BIT(FLASH->CR, FLASH_CR_LOCK) == 0U)
 {
 status = HAL_ERROR;
 }

 

 

In other words, flash is able to be unlocked for flash operations, but unable to be locked afterwards.

The weird thing is that we have another project, where we are using the same STM chip, but the project is much smaller, and there the same code works just fine without resulting in a Hard fault.

Right now I am at a loss as to what exactly is going on. Any help or suggestions what to do would be appreciated.

 

UPDATE:

I put some delay after setting the FLASH_CR_LOCK bit to 1. Now the Hard fault happens when it is in the HAL_Delay() function. So, after trying to lock the flash something happens and it triggers the Hard fault, but still not sure why.

[Lubos KOUDELKA]

Hello,
Do I understand correctly, that you're just running FLASH_EraseProgram example without any stack installed? In such case is not expected CPU2 is running and cannot impact CPU1 program execution. Or are you running the program after some bootloader using CPU2 (FUS?) and still with enabled CPU2?

[Sander_UP]

@Lubos KOUDELKANo, I am not running just the FLASH_EraseProgram, we have our own firmware where I am using the code form the FLASH_EraseProgram. There is no stack installed and everything related to CPU2 and the semaphore blocking has been left out. In Bootloader I am using the same code as in the "main" firmware (borrowed from the FLASH_EraseProgram example), but in the case for bootloader everything works correctly, only in the "main" firmware the same code does not work.

If I did not answer your question or You want extra information, please let me know.

[Lubos KOUDELKA]

Thank you for clarification. Do you have any screens from debug? Can you compare register content while executing your bootloader code and when accessing flash in your application? There need to be some difference visible in debug.

[Sander_UP]

I added three pictures of the flash registers:

1. firmware_flash_reg_after_flash_lock - Flash register after locking flash (breakpoint in hard fault).
2. firmware_flash_reg_after_flash_unlock - Flash register after unlocking the flash (LOCK bit in CR turned from 1 to 0).
3. firmware_flash_reg_before_flash_lock_3 - Flash register just before starting to lock the flash (before the SET_BIT(FLASH->CR, FLASH_CR_LOCK) is run).

The only difference I could see is that the LOCK bit in Flash register under CR turned from 1 to 0 after unlocking flash, but when trying to lock the flash the LOCK bit does set its value back to 1.

I also tried to clear some bits with this code snippet

 

 

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_EOP | FLASH_FLAG_OPERR | FLASH_FLAG_WRPERR | FLASH_FLAG_PGAERR | FLASH_FLAG_PGSERR | FLASH_FLAG_CFGBSY);

 

which I found in another thread about dealing with flash operations. But this also did not help.

[Lubos KOUDELKA]

In picture firmware_flash_reg_after_flash_lock.png I don't see FLASH_SR register to compare, suspicious from other pictures is set CFGBSY bit from FLASH_SR register. Are all operation finished prior to lock? Only double word (64 bits) can be programmed - please check application is not waiting for second word write.

[Sander_UP]

Yes, you are right, the CFGBSY is already set to 1 even before starting to lock the flash. And trying to clear the flag before even trying to do anything related to flash is not successful, the bit is not cleared (set to 0).

While debugging in the FLASH_WaitForLastOperation() function, it returns the timeout error.

 

EDIT: After debugging more, it seems that in the beginning of the program a function named HAL_PWR_EnableBkUpAccess() is called, and after that the CFGBSY is set to 1 and stays like that even when trying to clear it. Also, in the other project, where the flash operations are working, there is no such function, so that might explain why there is no such problem regarding flash operations.

And the HAL_PWR_EnableBkUpAccess() functions runs this line:

 

SET_BIT(PWR->CR1, PWR_CR1_DBP);

 

which enables access to the backup domain (RTC registers, RTC backup data registers). Also, there is a note saying that after reset, the backup domain is protected against possible unwanted write accesses. Does this also means that it disables access to flash (erase or write)?

 

EDIT2: When we were using BLE (stm32wb5x_BLE_Stack_full_fw v1.15.0 present), the flash operations worked fine with no problems. The function HAL_PWR_EnableBkUpAccess() was also used there.

[Sander_UP]

@Lubos KOUDELKA   Any ideas about why is this happening (regarding my previous reply)?

[Lubos KOUDELKA]

Hello,
I'm sorry, your edits were not giving me any change notification in this thread.
Still instead of trying to reset CFGBSY flag, I would rather focus on finishing the write, it shall reset busy flag. Can you please ensure your data are padded to 64bits to make sure 64bit write is finished?
PWR_CR1_DBP is impacting backup domain write protection (RTC and backup registers), flash write/erase access is not impacted by this bit.

[Sander_UP]

@Lubos KOUDELKAThe data is padded to 64bits. And thank You for the answer about the PWR_CR1_DBP bit. But is it normal that after running the line

HAL_PWR_EnableBkUpAccess();
// Which runs this line
SET_BIT(PWR->CR1, PWR_CR1_DBP);

the CFGBSY bit is set to 1 even though the flash write/erase is not related to it?