STM32G474 default option bytes configuration

[AShel.1]

Hello,

I've another observation, may be something wrong in board.

host controller is sTM32H573 which will update firmware of slave controllers interfaced on SPI one is sTM32G071 and is STM32G474, I'm using nucleo-g474re board

for sTM32g474 controller system memory boot configuration as per ref manual RM0440 Rev 4 pg no 89,

nBOOT1, nSWBOOT0 bits in option byte should be set to '1' and BOOT0 pin should be pulled high.

in reference manual RM0440 Rev 4 pg no 109 it is mentioned that default value of nSWBOOT0 bit is set to '1'. so no need to modify option byte to enable system memory boot.

I've tried reading option bytes of nucleo board(board is new) using STM32CubeProgrammer and it reads nSWBOOT0 as '0' if this is the case then again I'll have to modify option bytes to enable system memory boot. please check and provide your inputs.

[Amel NASRI]

Hi @AShel.1​ ,

Could you please check the revision of the device you are using (check DBGMCU_IDCODE on Address: 0xE004 2000)?

For Rev B devices nSWBOOT0=0, but then it was changed to nSWBOOT0=1. That is why default ST production value is 0xFFEF F8AA in RM0440 (please note that there is currently a rev5 of this document on the web).

-Amel

[AShel.1]

Hello,

if I read DBGMCU_IDCODE  0xE0042000 it gives value 0x20026469. how to decode revision? where it is mentioned if it is REV B device?

[CamTheMan]

If anyone here is looking for a solution to HAL_Delay blocking due to Systick ISR not working, refer to this thread. SysTick interrupt does not work - STMicroelectronics Community 

 

@Amel NASRI My Nucleo G474RET6U had nSWBOOT0 configured low, then I bought G474RET6 MCU separately and nSWBOOT0 was set high, are you saying at some point, ST revised this change? Both MCUs are Revision X so there was no indication that anything was different.