Error: Start operation failed at partition 0x01

[gil_he]

hello,

We get the error in the topic when trying to burn the FSBL using STM32CubeProgrammer.

It seems file download was successful and when running it, we got the error.

We have looked at https://community.st.com/s/question/0D53W000007Y3WmSAK/using-stm32cubeprogrammer-v220-to-program-sd-card-of-our-board-the-board-is-base-on-stm32mp157cdk2-but-fail-and-get-error-messageerror-start-operation-failed-at-partition-0x01error-tsv-flashing-service-failed

The issue in the link starts with partition 0x01 (FSBL), which is exactly what we see, but then changes to partition 0x03 (SSBL), which is not relevant for us.

How can we debug that? (we don’t have JTAG working).

Can that be related to the Clock Configuration in the STM32CubeMX? Will it help to send you a screen shot of the configuration?

thanks

Gil

[Neeraj Dantu]

Gil,

Can you post the output on your Cube Programmer command line as well as the output on the console for the board? The output on the console of the board should reveal the error that has occurred during the download.

Have you gone through the check items here: https://community.st.com/s/article/FAQ-STM32MP1-STM32CubeProgrammer-USB-reconnect-error-at-STM32MP1-boot-device-flashing?

Please also update the Cube Programmer on your machine as we have seen issues when using an incompatible version between Cube Programmer and OpenSTLinux.

Best,

Neeraj

 

[gil_he]

hello Neeraj,

I have gone through the article you sent.

It talks about the UBOOT (partition 3) which disconnects/re-initializes the USB and that may cause a reconnect to fail.

Does the FSBL (partition 1) also acts like that?

In my design, OTG_VBUS is connected to the VBUS pins of the USB3 type C connector we have in the board (we use it as USB2), so it gets the 5v from there.

The  OpenSTLinux version we use is “dunfell”. I installed the latest V2.12.0 CubeProgrammer.

Find enclosed the output of the CubeProgrammer during download (first pic is after connection. 2nd is after downloading).

We don’t have working UART port so cannot send the output on the console for the board (we will have UART only after UBOOT loads and we change pin muxing).

thanks

Gil

• This reply was modified 1 year, 10 months ago by gil_he.
• This reply was modified 1 year, 10 months ago by gil_he.
• This reply was modified 1 year, 10 months ago by gil_he.

Attachments:

1. 

   STMCubeProgrammer_1.png
   

2. 

   STMCubeProgrammer_2.png
   

3. 

   STMCubeProgrammer_1-1.png
   

4. 

   STMCubeProgrammer_2-1.png
   

[Neeraj Dantu]

Gil,

Please take a look at https://www.st.com/resource/en/application_note/an5275-usb-dfuusart-protocols-used-in-stm32mp1-series-bootloaders-stmicroelectronics.pdf for detailed information on the DFU protocol. The TF-A being sent over needs to initiate a DFU download of the next stage bootloader(u-boot), which is what is likely failing to do on your board. Please review your TF-A device tree: https://wiki.st.com/stm32mpu/wiki/USBPHYC_device_tree_configuration.

Best,

Neeraj

[gil_he]

hello Neeraj,

I’ve taken a correct CubeProgrammer sequence (from https://community.st.com/s/question/0D53W000007Y3WmSAK/using-stm32cubeprogrammer-v220-to-program-sd-card-of-our-board-the-board-is-base-on-stm32mp157cdk2-but-fail-and-get-error-messageerror-start-operation-failed-at-partition-0x01error-tsv-flashing-service-failed)
and compared to AN5275, figure 3, page 6.

I think, we passed the “Authenticate and start TF-A (in SYSRAM)”, so it seems our USBC port is configured as required (TF-A load is successful).
So, we are in either “Get boot config from BootRom” or “init clock and DDR” states.
Do you agree?
(I do not think we reached the “FlashLayout & start” state).

What can cause our start operation to fail?

Is it the files used to create the tf-a.stm32 binary?

Maybe the clock configuration tree?

Also:

The GenerateCode of the CubeMx gave us three files (under the TF-A folder):
stm32mp157c-lucid40_p1-mx-fw-config.dts
stm32mp157c-lucid40_p1-mx.dts
stm32mp15-mx.dtsi

The file, stm32mp157c-lucid40_p1-mx-fw-config.dts, has an include to a dtsi file which we don’t have.
It has only these two lines:
#define DDR_SIZE 0x20000000 /* 512MB */
#include “stm32mp15-fw-config.dtsi”

Should we rename the include to “stm32mp15-mx.dtsi”?

thanks

Gil

• This reply was modified 1 year, 9 months ago by gil_he.
• This reply was modified 1 year, 9 months ago by gil_he.

[Neeraj Dantu]

Gil,

It does seem that the board is able to boot via USB with the TF-A loaded. However, note that the USB configuration is from the internal ROM code. The TF-A also needs to be able to exercise the USB port correctly in order to load the next stage(U-Boot).

#include “stm32mp15-fw-config.dtsi” should already be part of the OpenSTLinux package you are using. This file is in ST’s sources: https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.6-stm32mp/fdts/stm32mp15-fw-config.dtsi

You mentioned that you cannot access the logs from the board because the UART4 interface is not accessible. You can change the console output in TF-A here: https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.6-stm32mp/fdts/stm32mp157c-dk2.dts#L28. Once you redirect the console output to a serial interface you can access, you can determine the error in boot more specifically.

Best,

Neeraj

[gil_he]

hello Neeraj,

(1)

Regarding the USB configuration:

We have the USB port in the SiP connected to a USB Type C connector.

VBUS in the connector is connected to the SiP.

Our device will act as a peripheral (device) and DRD. PA10 is not connected.

The only pins connected to the type C are USBDP2/DM2 and OTG_VBUS.

See enclosed picture from CubeMx: We defined OTG/Dual_Role_Device Type C and checked “Activate_VBUS”.

Is the following setup correct?

(2)

We don’t have any other UART pins, in the SiP, that can be routed to the debug connector.

The only pins are for UART4 but not the default ones, so, until we change it (in UBOOT), we cannot use it.

(3)

We connected the UART4 connector in the Octavo BRK and RED, and see giberish on the terminal.

Trying all available settings (translations, com settings) did not help.

Why can’t we see clearly the logs on uart4?

thanks

Gil

• This reply was modified 1 year, 9 months ago by gil_he.

Attachments:

1. 

   CubeMx_USB_OTG.png
   

[Neeraj Dantu]

Gil,

1. The hardware connections sound ok. One thing to check is the CC pin configuration. Are you using a USB-C controller chip like STUSB1600 to manage dual role function?

The CubeMX setup looks okay as well. I would check the device tree generated against a DK2/RED/BRK. Since the board connects to Cube Programmer initially, this feels like there is a configuration issue at TF-A. If you are using the same USB port and non-volatile memory interface(eMMC) as OSD32MP1-RED, you can use the same setup with a RED board to eliminate issues with the custom board as the cause for this issue.

2. Note that you can change pinmux settings in TF-A here: https://github.com/octavosystems/OSD32MP1-RED-Device-tree/blob/main/tf-a-v2.4-r0/stm32mp157c-osd32mp1-red.dts#L547

3. I am not quite sure what the setup is with the RED/BRK and which board firmware version you are using. I would start with https://github.com/octavosystems/meta-octavo-osd32mp1 since it is a known verified OpenST image. The UART settings should be 115200, 8N1. Gibberish on the terminal might also mean the host computer is not properly interpreting the data on the terminal. It might need a different terminal window or a reboot. See if you still see gibberish if you are entering data on that terminal via keyboard.

Best,

Neeraj

 

[gil_he]

Hi Neeraj,
1. We don’t use a chip like the STUSB1600. The SiP USB port is connected directly to the type c connector (as I described above).
The type C is just a connector. We work with it as if it’s USB2.
The CC pins are NC in the type C connector.
See attached picture. We also don’t use the OTG_HS_ID.
Setting on the CubeMX is OTG/Dual_Role_Device Type C and checked “Activate_VBUS”.
To your understanding, is that ok?

2. I tried many different setups using Putty. Always giberish.
I will further debug the uart4.

thanks

Gil

• This reply was modified 1 year, 9 months ago by gil_he.

Attachments:

1. 

   usb_lucid40.png
   

[Neeraj Dantu]

Gil,

I don’t think you can leave CC pins unconnected. Please review https://www.ti.com/lit/wp/slly017/slly017.pdf

As far as I can tell, the option for USB-C you specified does not seem to do anything except for enabling the USB ports. You can directly compare your board device tree USB setup with the BRK here: https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/master/tf-a-v2.4-r0/stm32mp157c-osd32mp1-brk.dts#L481. Note that the BRK uses a Micro-USB port.

 

Best,

Neeraj

[gil_he]

hi Neeraj,

An update:

I was able to receive readable uart4 output (not gibberish) ONLY when using the STLINK (as a uart to usb interface).

Direct connection of the SiP uart interface (via generic serial to usb), using numerous terminals, showed only gibberish.

thanks

Gil

 

 

[Neeraj Dantu]

Hey Gil,

It sounds like the application on your host machine works correctly. You can also do a quick check on the USB-UART cable and verify it independently. The next step then is to see if all your boards are having the same issue. If that is the case, the issue might be related to the firmware you are using. For example, if the UART peripheral is receiving the wrong clock ans not setup properly in the device tree, it is possible to have timing mismatches that could result in the gibberish you are seeing.

If you are still having issues, please feel free to contact us offline with more information on what you are seeing.

Best,

Neeraj

[gil_he]

Hi Neeraj,

Behavior is the same in BRK, RED and in our board.

The UART in the SiP sends the correct baud rate. In addition, electrically, the signals are correct.

It seems the debugger is sending the ascii symbols properly, and the terminal shows them correctly.

When connecting the SiP directly to a serial to usb and to a pc, I see gibberish.

The only explanation I have is, something in the debugger (fw or hw) translates the SiP uart correctly to the terminal.

Gil

[Neeraj Dantu]

Gil,

The conclusions we can draw from the behavior you are seeing are:

– UART output of the SiP is expected

– Your host computer is fine given that it can interpret ST Link’s UART signals

– Device frequency setting is good as you are able to decode signals from ST Link without issue.

Unless you can verify the UART-USB cable independently, I would assume that the cable is bad. May be take a look at the voltage setting on the cable(5V vs 3.3V)?

Best,

Neeraj

[gil_he]

Hi Neeraj,

The gibberish was shown using two different usb-serial adapters.

I know these adapters connect successfully to a 3.3V serial bus.

The only explanation I can find is that the stlink is specifically required to interpret correctly the SoC uart data.

I assume this can be verified with ST.

thanks

Gil

[Neeraj Dantu]

Gil,

Another thing to check is proper GND connection between the board and the UART cable. This method of communication is used all the time by most embedded developers. So, it is unlikely that there is an issue with the use case with 3 different boards.

Best,

Neeraj

[Author]

Posts