Uboot DFU not working
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-02-12 4:33 AM
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?
- Labels:
-
STM32MP15 Lines
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-02-12 11:18 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-02-14 1:25 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-02-14 2:07 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-02-14 2:59 AM
- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-02-14 6:04 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-02-17 12:00 AM
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-02-17 4:17 AM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-02-17 5:09 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-02-19 10:53 PM
Patrick,
Pin BYPASS_REG1V8 is connected to VDD1V8 and VDDA1V8_REG too.
We are using the STPMIC1B in the configuration like in figure 33.
