2024-07-29 06:16 AM
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?
2024-09-11 12:24 AM - edited 2024-09-11 01:18 AM
@Lubos KOUDELKA Any ideas about why is this happening (regarding my previous reply)?
2024-09-17 12:50 AM
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.
2024-09-23 04:38 AM - edited 2024-09-23 04:47 AM
@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?