Question about STM32 MCU that does not perform the program on it's flash memory, after turning it off, and then on.

[REldo.1]

Hi, 

I'm using STM32 MCU: STM32L4A6AGIxP.

The IDE that I use to write the code for the MCU is: STM32CubeIDE v1.10.1.

The BOOT0 pin of this MCU is floating and not connected to GND.

The big problem that the MCU is SMT FBGA type and and soldered to the PCB, 

so I can't detach it from the PCB and do a direct solder between the BOOT0 pin, to a resistor that connected to GND.

In the IDE, after flashing the MCU in debug mode, the program loaded and performed correctly, but after exiting from debug mode, powering off and powering on the PCB again, the MCU do nothing and doesn't preform the program.

I've noticed that the the program is still exist on the MCU's flash memory, from address 0x0800000, after turning off & on the MCU. 

I suspect that because the situation, that BOOT0 is floating, the program that was burned to the flash memory, isn't loaded to address 0x00000000 on this MCU's memory, and is not performed.

My question: What can I do now with the given situation, that BOOT0 pin is not connected to GND in the soldered smt-fbga MCU, in order to perfrom the flashed program? Can I set BOOT0 programmatically in this MCU model, so that after turning on the processor, the software that is burned on its flash memory will be executed?

Many thanks in advance, and best regards,

Ran

[KnarfB]

Read the Option bytes section in the reference manual. Seems possble by setting nSWBOOT0 and nBOOT0 bits accordingly. Use STM32CubeProgrammer.

hth

KnarfB

[Piranha]

RM0351 section 2.6.2 "Boot configuration for STM32L49x/L4Ax devices".

Setting nSWBOOT0=0 seems to be enough.

And next time read the AN4555 before designing PCB.

[REldo.1]

Thanks all,

How can I set nSWBOOT0 and nBOOT0 ?

My PCB supports J-link segger, not the ST-link offical debugger, and the problem is that STM32CubeProgrammer does not support J-link as I've seen, only ST-link, so how can I control the nSWBOOT0 & nBOOT0 parameters?

Thanks alot!

[Pavel A.]

The Segger software should have a way to program the option bytes.

[Piranha]

Personally I find it more robust to just program the FLASH_OPTR register with firmware.

Look for an example code in my posts in this topic:

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

[REldo.1]

Dear Pavel & Piranha,

I'm using 'SEGGER J-Flash v6.88c' software, I've searched there for an option to program the option bytes, but I didn't find this threre.

Do you know in which Segger software this option is included?  

And about the ' FLASH_OPTR' register, in the STM32CubeIDE, for the MCU that I'm working with (STM32L4A6AGIX), there is no an field called nBOOT0 & nSWBOOT0, as shown in the attached picture.

So how can I configure BOOT0 now, that in a programmatically way, the MCU will load the burned program, from flash to adress 0x00000000, and will run the program after turning it on.

Many Thanks!

[Pavel A.]

The option bytes are in addresses 0x1FFF7800-1FFF7820 (bank1)

On your picture are shown the flash control registers. They reflect the state of the option bytes in runtime.

The Segger J-LINK forum is here. You can ask them directly.

Their J-FLASH software has kind of scripting ability, one can write a script to manipulate the flash registers.

The best IMHO is to follow the advice of @Piranha : write a small program to set these bits. And be done with it. Run it in RAM, if your debugger allows this.

[Piranha]

Well, then I will kindly inform you that the SVD files (register descriptions) are just absolutely full of junk. It's not some bugs - basically every other peripheral/register has something wrong for every MCU. Look at the reference manual and you will see those bits.

@Pavel A.​, I'm not writing a separate program. I'm just checking the FLASH_OPTR register at boot in a normal firmware. Of course, the reconfiguration is done only if the bits are not at the necessary state. Such a solution has two advantages. First, one can flash the firmware to a new board/MCU and it configures itself at the first boot. Second, if some hacker manages to modify those bits, the firmware reconfigures them back to the desired state again at the next boot. That includes the RDP...

@KDJEM.1​, just another register with wrong bits in SVD files like in hundreds of other registers in all SVD files...

[KDJEM.1]

Hi @Piranha​ ,

Thank you for bringing this issue to our attention.

I confirm that the FLASH_OPTR register is wrongly described in the SVD file.

I reported this issue internally. 

Internal ticket number: 133087 (This is an internal tracking number and is not accessible or usable by customers).

Kaouthar