Error: Start operation failed at partition 0x01

Forums Devices OSD32MP15x Error: Start operation failed at partition 0x01

Viewing 15 reply threads
  • Author
    Posts
    • #13021
      Gil Hershmangil_he
      Participant

        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

      • #13048
        Neeraj Dantu
        Moderator

          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

           

        • #13120
          Gil Hershmangil_he
          Participant

            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 Hershmangil_he.
            • This reply was modified 1 year, 10 months ago by Gil Hershmangil_he.
            • This reply was modified 1 year, 10 months ago by Gil Hershmangil_he.
          • #13278
            Neeraj Dantu
            Moderator

              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

            • #13292
              Gil Hershmangil_he
              Participant

                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, 10 months ago by Gil Hershmangil_he.
                • This reply was modified 1 year, 10 months ago by Gil Hershmangil_he.
              • #13313
                Neeraj Dantu
                Moderator

                  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

                • #13315
                  Gil Hershmangil_he
                  Participant

                    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, 10 months ago by Gil Hershmangil_he.
                    Attachments:
                  • #13321
                    Neeraj Dantu
                    Moderator

                      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

                       

                    • #13322
                      Gil Hershmangil_he
                      Participant

                        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, 10 months ago by Gil Hershmangil_he.
                        Attachments:
                      • #13325
                        Neeraj Dantu
                        Moderator

                          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

                        • #13329
                          Gil Hershmangil_he
                          Participant

                            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

                             

                             

                          • #13332
                            Neeraj Dantu
                            Moderator

                              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

                            • #13338
                              Gil Hershmangil_he
                              Participant

                                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

                              • #13346
                                Neeraj Dantu
                                Moderator

                                  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

                                • #13348
                                  Gil Hershmangil_he
                                  Participant

                                    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

                                  • #13352
                                    Neeraj Dantu
                                    Moderator

                                      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

                                  Viewing 15 reply threads
                                  • You must be logged in to reply to this topic.