OSD32MP1-BRK booting to DFU mode?

[karlchansen]

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, 8 months ago by karlchansen. Reason: Add screen-shot

Attachments:

1. 

   DFU-Mode.png
   

[Neeraj Dantu]

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

[karlchansen]

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?

[Eshtaartha Basu]

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.

[geferay]

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.

[Neeraj Dantu]

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

[geferay]

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.

[Neeraj Dantu]

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

[karlchansen]

@ 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.

[Aedan Cullen]

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.

[Author]

Posts