Uboot DFU not working

[JVerb.1]

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]

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.

[JVerb.1]

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]

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

[JVerb.1]

• 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]

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

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.

Copyright 2010-2016 Tormod Volden and Stefan Schmidt

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

[JVerb.1]

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]

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