STM32MP1 Switch to Production Boot

[DPade.1]

I have a board where a secondary CPU can select the STM32MP1's boot mode.  On initial boot, the MP1 boots from NOR flash.  I can then send a command to the secondary CPU which switches the MP1's BOOTx pins to enable engineering boot and resets the MP1.  When I am done, I send a command to the secondary CPU to boot the MP1 from NOR flash.  However, after I switch out of engineering mode, the MP1 only runs the serial loader.  I have to power cycle the board to make the MP1 boot from NOR flash.  Also, I have to let the board sit for a few seconds before powering it up or the MP1 goes to serial loader again instead of NOR boot.

Is this a limitation of the MP1 boot process, or is there a way I can reset the MP1 to boot from NOR flash without cycling power?

[DPade.1]

Another strange note for this issue.  If I cycle power to the board within about 2 seconds, the MP1 boots to serial loader mode even without changing the boot pins at all.  If I keep power off for >3 seconds, the MP1 boots from NOR flash as expected.

In this case the STPMIC1 is kept on during boot select switching, so we have the 1nF cap connected between NRST and NRST_CORE and the 10nF cap on NRST_CORE is removed.

[PatrickF]

Hi @DPade.1 ,

I did not fully understand the setup, but maybe the NOR-Flash is not reset when there is NRST (usually by a power cycle ensured by STPMIC1). It could occur that NOR-Flash is setup by SW in some specific modes (i.e. 4-bits and/or DDR) which does not allows the BootROM to correctly read the FSBL, and so fall back to Serial-Boot.
BootROM expect to read the NOR-Flash in legacy SPI mode.

Maybe a dump of BootROM log could confirm. https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_trace_analyzer

Please clarify that you have an external device (MCU ?) playing with boot pins level ?
This is quite unusual, could you precise the rationale which need to switch back to Engineering boot on a product ?

Regards

[DPade.1]

Hello PatrickF, thanks for the response.

In my application the STM32MP1 does not have external RAM (DDR) and so I cannot use the standard ST programming tools which depend on a SSBL (u-boot).  Also, the MP1 is not the primary controller in this system, so I interface our own PC firmware loading tools through another controller (MP1's USB and UARTs are not directly exposed for PC access).  Thus, I use Engineering Mode to load the initial custom loader so I can transfer our bootloader program to QSPI.  Later I want developers to be able to debug the M4 code without opening and modifying the system hardware, so I want to keep the option to switch to engineering mode.  The fact that MP1 is not the primary CPU also explains why I do not connect the MP1's NRST to the STPMIC1's NRST as is done on the eval kits.

In retrospect, it might be better to try to utilize the serial loader mode instead of Engineering Mode for this purpose.  But in the end they accomplish the same goal and I don't need any special protocol for Engineering Mode.

You could be correct about the QSPI needing a reset, but my test A7 image just blinks some LEDs and doesn't touch the QSPI peripheral.  I assumed BootROM would re-init the QSPI, but perhaps it does not or is not able to.  I will try your suggestion.  I will also try connecting the BOOT0 pullup directly and see if it will boot consistently if I bypass the external boot select logic.

Lastly, the current version of the board does not allow me to use the BootROM trace analysis because I have an onboard CMSIS-DAP debugger that does not support dap-direct mode.  The next version will allow me to connect an St-Link V3 direct to the MP1.

[DPade.1]

Hello @PatrickF 

I have not tried to reset the QSPI yet, but I tried bypassing my boot switch logic by soldering the BOOT0 pullup directly to the BOOT0 pin (not going through a separate switch).  I am concerned that the STM32MP1 still does not consistently boot the QSPI image on power cycle even in this setup.  I would say in this setup, most of the time it loads the QSPI image, but every now and then the BootROM LED (PA13) stays on solid.  Could something like this be because I do not have the Low-Voltage/Brownout detector enabled...would that help?

[PatrickF]

Hi, please confirm you are using STM32MP15 or STM32MP13 as behavior might be slightly different.

Maybe your pull-up is not strong enough (especially if same pull-up go to more than a single BOOT pin). As there is embedded pull-down on BOOT pins (25-55 kOhms), we recommend individual 1 kOhms pullup on relevant BOOT pins to ensure correct high-level.

Could you check if PA13 'solid' is 5kHz toggling. This is the development boot case.
Real Boot Fail (continuous PA13 low) should not occur in most cases (i.e. no secure boot, no specific OTP settings) , but rather the BootROM should fall back to serial boot (PA13 5Hz toggling until USB DFU or UART recognized).

Is BOOT2 well managed too ? both BOOT0 and BOOT2 should change between NOR-Flash (0b001) and Development Boot (0b100). BOOT1 could be left open.

Maybe look also at NOR-Flash HOLD pin (usually on IO2 or IO3), which should have a pull-up as not driven by BootROM.

Really, BootROM trace dump using JTAG should help. Any way to solder wires to connected an external STLINK SWD ?

Regards.