on 2020-05-29 10:41 AM - edited on 2023-09-18 02:02 AM by Andris
If It is the first time the boot chain is starting but fails, please see the classical pitfall below to get help
You can also visit the FAQ STM32MP1 bring-up procedure to have more information on how to start.
https://community.st.com/t5/stm32-mpus/faq-stm32mp1-how-to-bring-up-stm32mp1/ta-p/49280
Other resources: STM32MPU forum https://community.st.com/t5/stm32-mpus/ct-p/stm32-mpus
STM32MPU knowledge base: https://community.st.com/t5/stm32-mpus/tkb-p/stm32-mpus-knowledge-base
ROM CODE makes auto detection of the HSE configuration (crystal or oscillator).
If TF-A reconfigures wrongly it can stop after reconfiguration.
See https://wiki.st.com/stm32mpu/wiki/Clock_device_tree_configuration_-_Bootloader_specific
-Check configuration I2Cbus connection to STPMIC
I2C bus for pmic is done at early phase and raises a panic when the bus fails to be enabled.
In OpenSTLinux by default, TF-A expects STPMIC on I2C4. If this is not the case on your design device tree and TF-A code have to be modified.
See https://wiki.st.com/stm32mpu/wiki/PMIC_hardware_components#TF-A
Symptoms: no MP1 USB profile returned upon host PC at enumeration
- PA13 is open-drain toggling slow (~5Hz) when BootROM is waiting USB/Serial connection
- PA13 is open-drain toggling fast (~5kHz) on engineering Boot
- PA13 is not toggling (i.e. Hi-z) if successful detection of FSBL from Flash
- PA13 is obviously not toggling if MP1 is maintained in Reset whatever the cause, NRST or NRST_CORE low, VDD or VDDCORE too low.
Check if the voltage on VDD_CORE, VDD
Check the NRST NRST_CORE level, should be high
Check if PWR_ON level, should be high
Since 2.X there are 2 TF-A binaries:
one to boot from serial link with USB/UART stack to interact with CubeProg
one to boot from flash device. It does not content serial stacks (USB,UART) to save space.
Since 3.X, one TF-A binary is compiled for a given boot device (USB, UART, SD-Card, eMMC,…)
Load TF-A in SYSRAM with STM32CubeProgrammer and Rom code from USB:
STM32_Programmer.sh -c port=usb1 -w ../build/trusted/tf-a-stm32mp157c-displayboard-mx-trusted.stm32 0x01 --start 0x01
NOTICE: CPU: STM32MP157CAB Rev.B
NOTICE: Model: Display Board
WARNING: VDD unknown
INFO: Reset reason (0x4):
INFO: Pad Reset from NRST
INFO: Using USB
INFO: Instance 2
INFO: Boot used partition fsbl1
ERROR: Boot interface 6 not supported
PANIC at PC : 0x2ffd5a99
Exception mode=0x00000016 at: 0x2ffd5a99
Note : In 3.x TF-A code boot_interface_selected = 6 means TF-A compilation STM32MP_USB_PROGRAMMER flag is not defined.
"Loading Environment from EXT4... Card did not respond to voltage select! "
(Instead of "Loading Environment from EXT4... OK")
This error is when SDCard never responds to Uboot commands.
TF-A boots correctly from SD Card but we cannot access to it from Uboot. Issue might come when sdmmc1 node contains wrong properties in Uboot dts file (power supply/level shifter properties).
Check if sdmmc node is adapted to your PCB design, with or without level shifter:
STM32MP1-SDMMC1 is directly connected to Sdcard socket (DK2 case) ,see as reference DK2 Uboot device sdmmc1 node
or
STM32MP1-SDMMC1 is connected to SDcard socket via a SDMMC level shifter (EV1 case), see as reference EV1 sdmmc1 node
https://wiki.st.com/stm32mpu/wiki/SDMMC_device_tree_configuration#DT_configuration_examples
Check some typical pitfall :
When DDR tests fail, results should be analyzed to see if fail occur on specific data or address.
A procedure is available in AN5168 §8.4 “Test flow” and §3.4 “PHY timings”.
The DDR settings in CubeMX DDR parameters are described in AN5168.
Impedance on DQ/DQS byte line can be modified AN5168 § 5 and relax timings AN5168 §6 to know
how to change them.
If your PCB layout regarding DRAM-STM32MP1 chipset is picked-up from ST PCB layout examples or from ST boards, DRAM should be successful. Signal integrity tests have been passed on the DRAM-STM32MP1 connexion.
Symptoms : ROM code does not start
-Uboot sees all // NAND partition
-CubeProg flash ok but with some "Skipping bad block at 0x07f80000" error message
The NAND is miss programmed by Uboot flash service because Uboot DT
shows properties that are not aligned with the chosen NAND data sheet:
nand-ecc-strength = <8>;
nand-ecc-step-size = <512>;
Further information under :https://wiki.st.com/stm32mpu/wiki/FMC_device_tree_configuration#DT_configuration_of_the_NAND_Flash_controller_-28board_level-29
Symptom : NAND can be accessed with Uboot but ROM code cannot boot from NAND
- OTP#9 configuration should be set according to NAND data sheet parameters (especially number of plane)
- Check NAND pin connections is compatible of the ROM code Serial NAND pins
- Check TF-A header
-Check configuration of all the memory pin : WP#/IO2 and HOLD#/IO3 pins.
ROMcode does not start
Check if OTP are virgin
Check pins out, power domain is ON for NAND supply
Check ONFI compatible nand otherwise OTP#9 configuration (see ROM code overwiew wiki article)
Check if NAND is not multiplane (not supported by ROM code)
If RevB Flash ONFI with 1-bit ECC does not work
Check vs mem DS Uboot ecc param in DT for FMC ecc algo selection (for flash Programming , Uboot does not rely on ONFI)
Uboot error :
"invalid MAC address in OTP 00:00:00:00:00
stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -3)"
This is not a critical error, but just a warning concerning the fact that the MAC address has not been written in the OTP of your device.
In this condition Linux kernel will use a random MAC address, so we can consider it as a warning only.
U-Boot instead will fail to initialize the Ethernet, so it's an issue only for U-Boot networking.
You can bypass it by setting the MAC address manually at u-boot prompt with the commands
setenv .flags ethaddr
setenv ethaddr 11:22:33:44:55:66
To continue the boot after setting MAC, type run bootcmd
Hi @debugging,
The links have now been updated. Thanks for your feedback!
Best regards,
Laurids
clicking on the link
https://wiki.st.com/stm32mpu/wiki/Clock_device_tree_configuration_-_Bootloader_specific
is still broken. the link would be helpful as I am facing the panic issue
A custom board with discrete power (no PMIC) and with crystal osc in hardware. The HSE is configured as crystal osc in CubeMX. So need to try further. Just after the cubeprogrammer flashes part 0x3 (FIP) panic occurs: The UART output shows:
PANIC at PC : 0x2ffec8f3
Exception mode=0x00000016 at: 0x2ffec8f3
Can someone please help to fix the link ?
Hi @debugging - the author of the Wiki has been notified about the issue.
I am working on finding an earlier version that includes the section you need, to help resolving your issue.
I will get back to you as soon as it's available.
Best regards,
Laurids
One week later..
Two weeks later....