OSD32MP1-BRK booting to DFU mode?

Forums Devices OSD32MP15x OSD32MP1-BRK booting to DFU mode?

Viewing 6 reply threads
  • Author
    Posts
    • #11298
      Karl Hansenkarlchansen
      Participant

        We have several BRK boards. One of them is consistently booting into DFU mode. Both Windows 10 and Linux (Ubuntu 20.04) report STM32MP1 in DFU mode.

        I have been unable to find any information on what would cause this, so I am looking for some guidance.

        None of the other BRK boards exhibit this behavior.

        • This topic was modified 3 years, 9 months ago by Karl Hansenkarlchansen. Reason: Add screen-shot
        Attachments:
      • #11316
        Neeraj Dantu
        Moderator

          Karl,

          Can you please check the boot configuration on the board? The boot configuration for SD card is described here: https://octavosystems.com/app_notes/osd32mp1-brk-getting-started/#boot. You can verify the switch positions are working correctly by probing the boot signals on the board. The layout files for the board are available here: https://octavosystems.com/octavo_products/osd32mp1-brk/#Design%20Files.

          Best,

          Neeraj

        • #11688
          Karl Hansenkarlchansen
          Participant

            The boot switches are as designated on the getting-started page. The BRK board was working fairly reliably, but more and more it is booting into DFU mode.

            Can we use “dfu-util” to force a boot from the SD card?

          • #11697
            Eshtaartha Basu
            Moderator

              Hello karlchansen,

              OpenSTLinux image provided by ST for their own DK2 and EV1 boards detects the state of on-board user buttons B3 and B4 during boot up. These buttons are pulled up by default on the board. A button press will pull them down and assert DFU mode or Android FastBoot mode. These modes could get forced when the pins are left floating too.

              See section 7.11.1 of https://www.st.com/resource/en/user_manual/dm00591354-discovery-kits-with-stm32mp157-mpus-stmicroelectronics.pdf for more info on these pins.

              ST DK2’s schematic –
              https://www.st.com/resource/en/schematic_pack/mb1272-dk2-c01_schematic.pdf

              Octavo BRK’s schematic –

              OSD32MP1-BRK Schematics

              ST DK2’s user button B3 corresponds to MP1 pin PA14
              ST DK2’s user button B4 corresponds to MP1 pin PA13

              Both PA13 and PA14 are left floating on BRK so ST’s OpenSTLinux image will get forced into DFU or FastBoot modes unless these pins are externally pulled high.

              The problem in your case is most likely one of the following:

              1. OpenSTLinux image from ST is being used on BRK instead of Octavo’s BRK image from our website
              2. The patches are not properly applied to Octavo’s BRK image

              Please double check the image on your uSD card and see if problem persists.

            • #11778
              Geoffrey Powell-Isomgeferay
              Participant

                Hello,

                We have a similar issue, but with our own board design.

                We are using the OSD32MP157-512M-IAA SIP for a device we designed, but we currently have a 2/9 failure rate where the failure is that the OSD32MP157-512M-IAA goes into DFU mode, even though it is set for booting from micro-SD card.

                We have 1K external pull-ups for for Boot 1 & Boot 2. For Boot 3, we rely on the pull-down inside the STM32MP1, inside the SIP.

                Are there any thoughts on what may be causing the device to get stuck in that mode, and what may be done to trouble-shoot it?

                Even if we load U-boot and Linux over the wire, it seems no use if we have to do that every boot. The 7 good units are working great, so we have a 78% success rate. All 9 units are identical, except for the failure of the 2 units. This also means it is not a problem with the board design, boot image, nor equipment connected, as the same of all these was used to test good and bad boards.

                • #11794
                  Neeraj Dantu
                  Moderator

                    geferay,

                    As aidancullen below states, please try and verify along with the boot mode settings(at the boot pin side of the boot mode resistors), whether the ROM code tries to get FSBL from the SD card. https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview provides an overview of the ROM code.

                    Best,

                    Neeraj

                  • #11799
                    Geoffrey Powell-Isomgeferay
                    Participant

                      Hi Neeraj,

                      We verified visually and with a meter that the boot settings are correct and the same as another unit which boots correctly. The SD card also seems fine. It’s a head-scratcher.

                    • #11803
                      Neeraj Dantu
                      Moderator

                        geferay,

                        Do you observe activity on SD card interface CLK/CMD? If you are, then ROM code is correctly evaluating the boot mode, and something is going wrong after.

                        Since you are measuring correct voltage at the boot pins, this might not reveal much, but what is the size of pull-ups you are using on the BOOT mode pins?

                        Best,

                        Neeraj

                    • #11787
                      Karl Hansenkarlchansen
                      Participant

                        @ https://octavosystems.com/forums/users/eshtaartha/

                        NO, we have been and CONTINUE using the Octavo-provided. This is an image which previously always booted properly.

                        The only possible changes are possibly wear and/or corrosion on the switches preventing them from making good contact, or something internal to the chip.

                        Now, if the chip shows up in DFU mode, how do we kick it OUT of dfu mode?

                        Again, this is NOT, and CANNOT be a problem with the image, because it was previously working fine and HAS NOT CHANGED.

                      • #11789
                        Aedan Cullen
                        Participant

                          It seems to me that an intermittent issue with the boot device would cause the boot ROM to fall back into serial DFU mode even if the boot pins are strapped correctly. According to ST’s ROM code overview on their wiki, if the FSBL cannot be loaded, in basically every configuration you will fall through to serial boot (UART or USB DFU). So the following things come to mind:

                          – Have you tried a different SD card?

                          – For issues with a custom board, have you checked the SD interface with a scope or logic analyzer to see if it looks like the ROM is trying and failing to load the FSBL from the card?

                          – Especially with a custom board, what do you see on the UART when you are trying to boot?

                          According to that wiki page, there’s no way to instruct the device to exit DFU mode once you’re there. You have to do a reset and get the ROM code to first read the correct strap pins (which I would bet is probably working fine), and then load the FSBL successfully (which I believe could fail due to various minor issues with the SD/MMC device itself or its interface).

                          • This reply was modified 3 years, 2 months ago by Aedan Cullen.
                      Viewing 6 reply threads
                      • You must be logged in to reply to this topic.