How to read protect the code on F407VG

[Robmar]

I thought this would be simple, open up the STMCubeProgrammer, connect to the programmed device, select RDP, select BB read protection (CC means the MCU can never be reprogrammed so no user-done code updates!!) and then Apply!

But no, the board screen goes blank and it stops working!

Anyone got this working...? (for sure I missed something obvious?!)

[Piranha]

After the RDP is set, the MCU detects the debugger and locks. Do the power cycle (not just reset) and it will run.

[Robmar]

I did power cycle it, it still didn't work

[Tesla DeLorean]

You can also set it from your own application code, probably selectively/interactively after tests indicate it's working.

[Robmar]

Okay, but how?

[Robmar]

I found a post that clarified the situation here: after read out protection stm32f4xx stop working

Once read protection is set the debug port cannot be used to power the device. It can only be powered directly and the debug USB port must be left disconnected. Would have been useful if that could have been highlighted in big letters somewhere.

The following code then allows the device to set the RDP itself, is this correct?

FLASH_OBProgramInitTypeDef pObStruct;
HAL_StatusTypeDef status;
send(''Locking process initialized'');
HAL_FLASH_Unlock();
send(''Flash unlock done'');
HAL_FLASH_OB_Unlock();
send(''Option bytes unlock done'');
__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_EOP);
__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_WRPERR);
__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_PGAERR);
__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_PGPERR);
__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_PGSERR);
__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_BSY);
send(''all flgs are cleared'');
HAL_FLASHEx_OBGetConfig(&pObStruct);
if (pObStruct.RDPLevel == OB_RDP_LEVEL0)
{
send(''RDP level 0 found'');
pObStruct.OptionType = OPTIONBYTE_RDP;
pObStruct.RDPLevel = OB_RDP_LEVEL1;
send(''set level-1 process initialized'');
status = HAL_FLASHEx_OBProgram(&pObStruct);
send(''RDP memory flags updated'');
if(status == HAL_OK)
{
LED_YELLOW_ON;
send(''Optionbyte launch process initiated for RDP change'');
HAL_FLASH_OB_Launch(); 
send(''Optionbyte sucessfully launched'');
HAL_FLASH_OB_Lock();
send(''Option byte locked'');
HAL_FLASH_Lock();
send(''Flash locked'');
LED_YELLOW_OFF;
send(''System reset initialized'');
NVIC_SystemReset();
send(''blank check'');
LED_RED_OFF;
}
}

[Piranha]

Just disconnect the debugger by pulling off both jumpers from CN3 and you can continue using the debugger's USB port.

Normal code always checks/configures all option bytes and is much more reliable and simpler:

https://community.st.com/s/question/0D53W00001Uz40QSAR/what-causes-halflashobunlock-to-call-hardfaulthandlerit-calls-writeregflashoptkeyr-flashoptkey1-and-jumps-directly-to-hardfaulthandler

[Robmar]

Thanks, good to know

[Tesla DeLorean]

Code you have running in the part, can read the content. Dump data, output diagnostics, and interact.

You can also update application code via the access methods you provide yourself. There are likely to be sectors in the front that aren't usable for application/erasure (ST frequently write protects several sectors is these modes), but that's where you put your loader code, that a) facilitates update of the the application code deep into the flash (say 128K in), and b) validates/authenticates the application code before transferring control. The App code can provide additional update methods, say OTA.

How many doors and windows your house has, is entirely up to you..

[RhSilicon]

Hi, I use Linux and STM32CubeIDE to program the STM32F407VGT6, it has happened that this MCU stops responding to STlink.

I was able to resolve this just using the STlink utility tool on Windows, I erased all the STM32 Flash. Then STlink recognized the STM32 on Linux.

I don't know if the STM32CubeProgrammer solves it too.