STM32L152RET6 - BOR Setup failed

[nhernandez4i]

Hi folks, this is my first post here on this forum and I expect to find an answer to this issue I currently have.

Just so you know, my current hardware setup involves an STM32L152RET6  MCU on our custom board which we have been able program using a Nucleo board in ST LINK mode.

The problem is that I haven´t been able to set the BOR level using the STM32CubeProgrammer software and also tried to set the BOR through our firmware using some code I found somewhere on this forum involving HAL_FLASHEx_OBGetConfig, HAL_FLASHEx_OBProgram and HAL_FLASH_OB_Launch functions. Results were the same for both methods: The MCU restarts after OB Launch and gets stuck un lockup mode with no ability to flash any firmware .bin or mass erase the MCU.

When reading option bytes register in STM32CubeProgrammer an error appears saying that I have to check memory protection. RDP was set to AA before trying to set the BOR value. After setting the BOR level value the STM32CubeProgrammer shows "0" on the RDP field and  BOR shows value "0" as well. It is as if all values were cleared to "0" or that the read protection does not allow me to read such values.

Also, MCU flash mass erase fails as well.

Has somebody found a solution to this? 

Thanks

[TDK]

Can you use STM32CubeProgrammer to change BOR on a Nucleo board (known good hardware)?

> using some code I found somewhere on this forum

Can you provide a link to said random code? Or provide the code you are using? Hard to debug that which cannot be seen.

Can you recover the chip by holding BOOT0 high during reset? Or is the chip effectively bricked now?

[nhernandez4i]

Hello,

 

Havent tried changing the BOR on the Nucleo board we have. I did not want to try this because I was afraid of "bricking" the Nucleo board. Guess there is no other choice than to try this.

regarding the code here is the code intructions being used:

int main(void)
{
 
 // Use this to enable SWV printf
 // Enable TRCENA
 DEMCR |= ( 1 << 24);
 // Enable stimulus port 0
 ITM_TRACE_EN |= ( 1 << 0);

 /* set example to const : this const changes in binary without rebuild */
 pUserAppId = (uint8_t *)&UserAppId;

 /* Initialize Clock, DMA, and peripherals only configured in HAL modules */
 Board_Init();

 /* Initialize peripherals shared between HAL and custom modules-----------*/
 MX_USART1_UART_Init();

//>>>>>>>>>>>>> Here is the Ooption Bytes change code
/*
	 FLASH_OBProgramInitTypeDef OptionBytes;
	 HAL_FLASHEx_OBGetConfig(&OptionBytes);

	 printf("BOR LEVEL = 0x%04X", OptionBytes.BORLevel);
	 printf("Option Bytes = 0x%04X", OptionBytes.USERConfig);
	 printf("BOR_LEV = 0x%X", (unsigned int)(OptionBytes.USERConfig & OB_USER_BOR_LEV));

	 if ((OptionBytes.USERConfig & OB_USER_BOR_LEV) != OB_BOR_LEVEL3)
	 {
	 printf("Brown out reset not set to Level 5 (approximately 2.9V)");
	 HAL_FLASH_Unlock();
	 HAL_FLASH_OB_Unlock();
	 OptionBytes.OptionType = OPTIONBYTE_USER;
	 OptionBytes.USERConfig = OB_BOR_LEVEL5;

	 if (HAL_FLASHEx_OBProgram(&OptionBytes) != HAL_OK)
	 {
	 HAL_FLASH_OB_Lock();
	 HAL_FLASH_Lock();
	 return HAL_ERROR;
	 }
	 HAL_FLASH_OB_Launch();
	 /* We should not make it past the Launch, so lock
	 * flash memory and return an error from function
 /*
	 HAL_FLASH_OB_Lock();
	 HAL_FLASH_Lock();
	 }

	 printf("BOR LEVEL after = 0x%04X", OptionBytes.BORLevel);
	 printf("Option Bytes = 0x%04X", OptionBytes.USERConfig);
*/
//<<<<<<<<<

 while(1)
 {
 userApp();
 }
}

I think I took the code from this site

Also there are other st users with the same problem and no solutions

Here  and here 

I tried holding BOOT0 high during reset with no results.

 

[TDK]

I'm not really sure. But I do suspect there is a reasonable explanation.

Modifying option bytes at the beginning of the program can cause issues, particularly since the debugger starts the program multiple times when you hit "Run" and if it launches option bytes, the debug connection will fail. Putting a 1s delay can mitigate that issue.

Resetting with BOOT0 really should allow you to recover the chip.

[nhernandez4i]

It is really strange because setting the BOR via software (with the given code) and via STM32Programmer bricks the MCU, so I get the same result via two different ways.