Uboot DFU not working

JVerb.1 · ‎2020-02-12

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?

PatrickF · ‎2020-02-12

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.

JVerb.1 · ‎2020-02-14

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 · ‎2020-02-14

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.

JVerb.1 · ‎2020-02-14

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.

JVerb.1 · ‎2020-02-14

Below the answers:

Please check the uBoot log on device UART, maybe uBoot is crashing.

Done: U-Boot does not crash, we have the logs. We can interrupt U-Boot and get a prompt.

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.

We are not using a VM but a container on a Linux machine. The container is configured to let the USB through. It seems OK, as we do have a correct DFU upload over USB (when running the Boot ROM code), and as we do have a successful full upgrade of the DK2, from the same container.

We have tried with the STM32CubeProgrammer installed on a Windows machine: same effect. DFU transfers are OK when the USB is configured by the Boot ROM, and not OK when U-Boot takes the hand and reconfigures the USB.

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)

We have tried "-tm 20000": no change. The CubeProgrammers times out after the reconnect, because the USB is not correctly re-enumerated. Log is:

Memory Programming ...

Opening and parsing file: u-boot-stm32mp157c-ev1-trusted.stm32

File : u-boot-stm32mp157c-ev1-trusted.stm32

Size : 768148 Bytes

Partition ID : 0x03

Download in Progress:

[==================================================] 100%

File download complete

Time elapsed during download operation: 00:00:00.846

RUNNING Program ...

PartID: :0x03

reconnecting the device ...

Error: unable to reconnect the target device: time out expired

Error: Start operation failed at partition 0x03

Error: TSV flashing service failed

The kernel log contains the following traces:

Feb 14 13:59:29 ThinkPad-E560 kernel: usb 1-3: new high-speed USB device number 6 using xhci_hcd

Feb 14 13:59:29 ThinkPad-E560 kernel: usb 1-3: New USB device found, idVendor=0483, idProduct=df11, bcdDevice= 2.00

Feb 14 13:59:29 ThinkPad-E560 kernel: usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3

Feb 14 13:59:29 ThinkPad-E560 kernel: usb 1-3: Product: DFU in HS Mode @Device ID /0x500, @Revision ID /0x0000

Feb 14 13:59:29 ThinkPad-E560 kernel: usb 1-3: Manufacturer: STMicroelectronics

Feb 14 13:59:29 ThinkPad-E560 kernel: usb 1-3: SerialNumber: 004400273438510131393233

Feb 14 13:59:29 ThinkPad-E560 mtp-probe[8349]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"

Feb 14 13:59:29 ThinkPad-E560 mtp-probe[8349]: bus: 1, device: 6 was not an MTP device

Feb 14 13:59:29 ThinkPad-E560 fwupd[2931]: 12:59:29:0548 FuPluginDfu DFU version 0x0000 invalid, v1.1 assumed

Feb 14 13:59:29 ThinkPad-E560 mtp-probe[8368]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"

Feb 14 13:59:29 ThinkPad-E560 mtp-probe[8368]: bus: 1, device: 6 was not an MTP device

[...]

Feb 14 13:59:36 ThinkPad-E560 kernel: usb 1-3: USB disconnect, device number 6

Feb 14 13:59:39 ThinkPad-E560 kernel: usb 1-3: new high-speed USB device number 7 using xhci_hcd

Feb 14 13:59:44 ThinkPad-E560 kernel: usb 1-3: device descriptor read/64, error -110

Feb 14 14:00:00 ThinkPad-E560 kernel: usb 1-3: device descriptor read/64, error -110

Feb 14 14:00:00 ThinkPad-E560 kernel: usb 1-3: new high-speed USB device number 8 using xhci_hcd

Feb 14 14:00:05 ThinkPad-E560 kernel: usb 1-3: device descriptor read/64, error -110

Feb 14 14:00:21 ThinkPad-E560 kernel: usb 1-3: device descriptor read/64, error -110

Feb 14 14:00:21 ThinkPad-E560 kernel: usb usb1-port3: attempt power cycle

Feb 14 14:00:22 ThinkPad-E560 kernel: usb 1-3: new high-speed USB device number 9 using xhci_hcd

Feb 14 14:00:27 ThinkPad-E560 kernel: usb 1-3: device descriptor read/64, error -110

Feb 14 14:00:43 ThinkPad-E560 kernel: usb 1-3: device descriptor read/64, error -110

Feb 14 14:00:43 ThinkPad-E560 kernel: usb 1-3: new high-speed USB device number 10 using xhci_hcd

Feb 14 14:00:48 ThinkPad-E560 kernel: usb 1-3: device descriptor read/64, error -110

Feb 14 14:01:03 ThinkPad-E560 kernel: usb 1-3: device descriptor read/64, error -110

Feb 14 14:01:04 ThinkPad-E560 kernel: usb usb1-port3: unable to enumerate USB device

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

No, but as our U-Boot runs without error, I think our DDR is OK. We will check it later.

PatrickF · ‎2020-02-17

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.

JVerb.1 · ‎2020-02-17

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 · ‎2020-02-17

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.

JVerb.1 · ‎2020-02-19

Patrick,

Pin BYPASS_REG1V8 is connected to VDD1V8 and VDDA1V8_REG too.

We are using the STPMIC1B in the configuration like in figure 33.