U385 EEPROM/Flash writing is giving me a headache

[george-metasphere]

In the past I've used F401 and the following code works flawlessly

HAL_FLASH_Unlock();
HAL_ICACHE_Disable();
uint64_t myWord = 0x00000001;
HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, 0x080C0000, myWord);
HAL_GPIO_WritePin(LD2_GPIO_Port, LD2_Pin, GPIO_PIN_SET);
HAL_FLASH_Lock();
HAL_ICACHE_Enable();

Now, after switching to U385, i only get grief, with any Write command exiting in HardFault_Handler(). My research points to Option Bytes - Write Protection being enabled but the GUI in STM32CubeProgrammer is very confusing for U385, and it seems that I may have permanently locked the MCU? I cannot tick back the UNLOCK_1A _1B _2A and _2B flags. How can one unlock the Flash fully in U3?

[KDJEM.1]

Hello @george-metasphere and welcome to the community;

 

Could you please check the RDP level?

UNLOCK option bits can be set only when regressing from RDP level 1 to level 0.

Each WRP area can be independently locked by writing 0 to the UNLOCK bit in FLASH_WRP1AR, FLASH_WRP1BR, FLASH_WRP2AR, or FLASH_WRP2BR. Once a WRP area is locked, it is not possible to modify its settings. In order to unlock a WRP area, a regression to RDP level 0 must be launched.

For more information about the UNLOCK options bytes, I recommend you to look at RM0487 section 7.6.1 Write protection (WRP).

An example of FLASH_EraseProgram has been tested with NUCLEO-U385RG-Q board may help you.

 

Thank you.

Kaouthar

[george-metasphere]

The FLASH_EraseProgram works with the condition hit:

/* No error detected. Switch on LD2 */
 BSP_LED_On(LD2);

But I'm still puzzled by CUBEProgrammer as the UNLOCK_ flags are still unticked and I can't tick them back. In CLI, after doing "STM32_Programmer_CLI -c port=SWD -ob UNLOCK_1A=1", i get back:

OPTION BYTE PROGRAMMING VERIFICATION:

Error: Expected value for Option Byte "unlock_1a": 0x1, found: 0x0
Error: Option Byte Programming failed Or modified by application after OB_LAUNCH

Time elapsed during option Bytes configuration: 00:00:06.443


Again, the CubeProgrammer Write Protection settings for U385 looks very different than the older MCUs

[KDJEM.1]

Hello @george-metasphere ;

 

As, I mentioned in the my last reply, before setting UNLOCK options bytes it is required to regret the RDP level.

UNLOCK option bits can be set only when regressing from RDP level 1 to level 0.

You can find more information of RDP level in this wiki: Security:RDP for STM32U3 - stm32mcu.

 

Thank you.

Kaouthar

[george-metasphere]

Sorry, forgot to mention that the RDP level is already set to AA : Level 0, no protection.

[KDJEM.1]

Hi @george-metasphere,

 

Could you please try this sequence using STM32CubeProgrammer

• Set RDP Level 1
• Set RDP Level 0 + tick UNLOCK both at same time

 

Thank you.

Kaouthar

[george-metasphere]

Finally! This was the solution. Not very straightforward though and not sure if this was indented or a bug in the UI.

[george-metasphere]

But this still doesn't answer my question on why writing a value onto a specific address in the flash would render a Hardfault

[KDJEM.1]

Hello @george-metasphere;

 

I cannot tick back the UNLOCK_1A _1B _2A and _2B flags. How can one unlock the Flash fully in U3?

Glad to know that you can tick back the UNLOCK. 

To check the HardFault, I recommend you to look at How to debug a HardFault on an Arm® Cortex®-M STM32 article, this article explain how to debug faults on Arm Cortex®-M based STM32 devices.

 

I hope this help you.

Thank you.

Kaouthar