Associate

Question

Uboot DFU not working

Forum|Forum|6 years ago
February 12, 2020
3 replies
2658 views

We have build a device that looks like DK2 but we have a NAND memory instead of SD card and we work on an IO supply of 1.8V instead of 3.3V.

We can load the fsbl and U-Boot with STM32cubeprogrammer, but U-Boot resets the usb and the STM32cubeprogrammer can never reconnect.

The board is not enumerated the second time.

How can we debug that?

What could be the cause?

STM32MP15 Lines

This topic has been closed for replies.

PatrickF

Technical Moderator

Hello,

one common pitfall is the HSE bypass configuration. Our deliveries assume (as for DK2 and EV1) that HSE is in digital bypass (i.e. fed from external oscillator).

If you use a Crystal, you should modify the DeviceTree (see https://wiki.st.com/stm32mpu/wiki/Clock_device_tree_configuration_-_Bootloader_specific#DT_configuration_for_HSE)

Note that FSBL and UBoot are loaded correctly because the BootROM has automated configuration of HSE mode (when USB boot is used with CubeProgrammer) whereas uBoot rely on Device Tree.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.Tip of the day: Try Sidekick STM32 AI agent, see here

JVerb.1Author

Associate

Hello Patrick,

We are using also an external oscillator but a variant on 1.8V. Furthermore it's the same circuit.

FSBL and UBoot are booting without errors on the console.

Are there other possibilities?

Regards,

Jan

PatrickF

Technical Moderator

Few thoughts:

Please check the uBoot log on device UART, maybe uBoot is crashing.
If you are using a VM, check the USB 'connection' between Linux and Windows as uBoot reconnect using a different USB identification and might not be 'routed' to the VM.
You could try adding "-tm 20000" to the CubeProgrammer command line (allow more time for the USB to be up and running on PC side)
Did you succeed to run DDR Tools (need to use basic boot with an uBoot-SPL binary) ? See CubeMX https://wiki.st.com/stm32mpu/wiki/STM32CubeMX

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.Tip of the day: Try Sidekick STM32 AI agent, see here

JVerb.1Author

Associate

There is no error on the UART console.
We tried this on a windows and a Linux computer (No NM). Both the same result.
We will try this.
We didn't run the DDR tool. We will try that too.

I will come back to you with the aswers.

PatrickF

Technical Moderator

Hi,

As after the failing download you should have access to the U-Boot console using UART,

you can try a simple ‘dfu’ command just to be sure that USB device mode and DFU is correctly managed in U-Boot with your device tree.

STM32MP> env set dfu_alt_info "DDR ram 0xC0000000 0x20000000"
STM32MP> dfu 0 ram 0

This U-Boot command is infinite, USB stack continue until Ctrl+C….

Now you should see the USB on the PC side.

on the PC, for example:

$> dmesg

....

[xx] usb 5-1.3.1.2: new high-speed USB device number 10 using xhci_hcd

[xx] usb 5-1.3.1.2: New USB device found, idVendor=0483, idProduct=df11

[xx] usb 5-1.3.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[xx] usb 5-1.3.1.2: Product: USB download gadget

[xx] usb 5-1.3.1.2: Manufacturer: STMicroelectronics

[xx] usb 5-1.3.1.2: SerialNumber: 003A00203438510D36383238

....

$> lsusb

…

Bus 005 Device 010: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

…

$> lsusb -d 0483:df11 -v

Bus 005 Device 010: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

Device Descriptor:

bLength 18

bDescriptorType 1

bcdUSB 2.00

bDeviceClass 0 (Defined at Interface level)

bDeviceSubClass 0

bDeviceProtocol 0

bMaxPacketSize0 64

idVendor 0x0483 STMicroelectronics

idProduct 0xdf11 STM Device in DFU Mode

bcdDevice 99.99

iManufacturer 1 STMicroelectronics

iProduct 2 USB download gadget

iSerial 3 003A00203438510D36383238

bNumConfigurations 1

Configuration Descriptor:

bLength 9

bDescriptorType 2

wTotalLength 27

bNumInterfaces 1

bConfigurationValue 1

iConfiguration 2 USB download gadget

bmAttributes 0xc0

Self Powered

MaxPower 2mA

Interface Descriptor:

bLength 9

bDescriptorType 4

bInterfaceNumber 0

bAlternateSetting 0

bNumEndpoints 0

bInterfaceClass 254 Application Specific Interface

bInterfaceSubClass 1 Device Firmware Update

bInterfaceProtocol 2

iInterface 5 DDR

Device Firmware Upgrade Interface Descriptor:

bLength 9

bDescriptorType 33

bmAttributes 15

Will Detach

Manifestation Tolerant

Upload Supported

Download Supported

wDetachTimeout 0 milliseconds

wTransferSize 4096 bytes

bcdDFUVersion 1.10

Device Qualifier (for other device speed):

bLength 10

bDescriptorType 6

bcdUSB 2.00

bDeviceClass 0 (Defined at Interface level)

bDeviceSubClass 0

bDeviceProtocol 0

bMaxPacketSize0 64

bNumConfigurations 1

Device Status: 0x0001

Self Powered

Now if your PC see the device (enumeration is OK), you can try dfu-util

$> dfu-util -l

dfu-util 0.9

This program is Free Software and has ABSOLUTELY NO WARRANTY

Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=9999, devnum=10, cfg=1, intf=0, path="5-1.3.1.2", alt=0, name="DDR", serial="003A00203438510D36383238"

$> dfu-util -a 0 -U ram.bin

……

If this test failed you have issue in U-Boot (PHY or controller, code or device tree).

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.Tip of the day: Try Sidekick STM32 AI agent, see here

JVerb.1Author

Associate

Thanks Patrick, you have helped us.

We have run the U-Boot commands you have proposed:

STM32MP> env set dfu_alt_info "DDR ram 0xC0000000 0x20000000"

STM32MP> dfu 0 ram 0

and on our laptop, the kernel log shows no USB enumeration but an error:

Feb 17 10:21:20 olheureu-ThinkPad-E560 kernel: usb 1-3: new high-speed USB device number 8 using xhci_hcd

Feb 17 10:21:25 olheureu-ThinkPad-E560 kernel: usb 1-3: device descriptor read/64, error -110

You stated:

If this test failed you have issue in U-Boot (PHY or controller, code or device tree).

We think we have an error in the PHY, controller, code or device tree indeed! But in which of the four? Our schematics is quasi-identical to the DK2 schematics, for the USB OTG part in particular, and most of the rest. (We use a CAD package instead of a CAC, so the pinout is different, we have the serial console on USART2 instead of UART4, we boot from a NAND flash, we have no Bluetooth, no Ethernet, no USB host...) The U-Boot code is not changed much. We have disabled "CONFIG_NET".

Do you know what we could check for a functional USB? Regulators, readiness or right state seen in some controller register?

PatrickF

Technical Moderator

As you mention earlier that you use VDD=1.8V, did you ensure the VDDA1V8_REG is supplied by VDD (or another 1.8V supply which is present whenever USB is used) with BYPASS_REG1V8=VDD ?

To have USB working, many supplies are required (VDDA1V8_REG, VDDA1V1_REG, VDD3V3_USB).

For typical supply connection using VDD=1.8V, you could have a look to Figure 33 in AN5031

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.Tip of the day: Try Sidekick STM32 AI agent, see here

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded