• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 701 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

DRA821U: U-Boot Loading trough USB.

DRA821U: U-Boot Loading trough USB.

Roberto Masi
Prodigy 70 points
Part Number: DRA821U
Other Parts Discussed in Thread: DRA821

I have tried to load u-boot via usb to flash ospi and mmc.

Using the J721EVM it works fine. Looking at the first step the command 

dfu-util -v -R -a bootloader -D tiboot3.bin 

is performed with success

libusb version 1.0.24 (11656)
Warning: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6164
Device DFU version 0110
DFU attributes: (0x07) bitCanDnload bitCanUpload bitManifestationTolerant
Detach timeout 65535 ms
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 512
Copying data from PC to DFU device
Download [=========================] 100% 527357 bytes
Download done.
Sent a total of 527357 bytes
DFU state(6) = dfuMANIFEST-SYNC, status(0) = No error condition is present
DFU state(2) = dfuIDLE, status(0) = No error condition is present
Done!
can't detach
Resetting USB to switch back to Run-Time mode

but when I try to perform the same operation on a custom board I see:

libusb version 1.0.24 (11656)
Warning: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6164
Device DFU version 0110
DFU attributes: (0x07) bitCanDnload bitCanUpload bitManifestationTolerant
Detach timeout 65535 ms
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 512
Copying data from PC to DFU device
Download [ ] 0% 0 bytesError during download (LIBUSB_ERROR_PIPE)

Enumeration and dfu-util -l commands works always fine:

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to sourceforge.net/.../

Found DFU: [0451:6164] ver=0200, devnum=1, cfg=1, intf=0, path="2-1", alt=1, name="SocId", serial="01.00.00.00"
Found DFU: [0451:6164] ver=0200, devnum=1, cfg=1, intf=0, path="2-1", alt=0, name="bootloader", serial="01.00.00.00"

The main difference is that on the custom board I use a standard USB 2.0 connector and only USB0 DP (AA2) USB0 DM(AA3) USB0_VBUS(Y2) processor pins are connected to the PC,
and the Demo board uses a Usb 3.1 TYPEC connector. Maybe this is the cause of the failure? Is there anything else I can check on the custom board?

Regards

Roberto

  • 0 in reply to Keerthy J
    Prodigy 70 points

    Hi Keerty,

    the u-boot generated files does not seems to be the problem. The files are loaded correctlly on my demo board.

    The problem comes up when i try to load tiboot3.bin on my custom board. In that phase I assume the processor is running internal ROM code but the transfer does not start and ends with LIBUSB_ERROR_PIPE.

    I assume that there is something related to my custom board, but I don't understand what is wrong.

    Regards

    Roberto

  • 0 in reply to Roberto Masi
    TI__Guru**** 166450 points

    Hi Roberto,

    Any device tree changes that were done from your side on the custom board to reflect the USB2 changes?
    Any logs that you can share on the device side(DRA821) side for DFU boot?

    Best Regards,
    Keerthy

  • 0 in reply to Keerthy J
    Prodigy 70 points

    Hi Keerty,

    I didn't modidy the device tree up to now. In a previous post I understood there was nothing to change.

    Are there device tree modification to be done for the next steps booting?

    About logs, the board seems to log nothing before loading tiboot3.bin. The problem is that the transfer of that file (tiboot3.bin) does not begin a all, and from what I understtod from documentation in that phase the processor is only running ROM code am I wrong?

    Regards

    Roberto

  • 0 in reply to Roberto Masi
    TI__Guru**** 166450 points

    Hi Roberto,

    Could you clarify the exact HW difference w.r.t USB on your custom board? I can check with hardware experts internally
    on the functionality.

    Best Regards,
    Keerthy

  • 0 in reply to Keerthy J
    Prodigy 70 points

    Hi Keerthy

    I have a usb type a connector with USB0_DP(AA2) and USB0_DM(AA3) connected to its pins through an  ACT1210 common mode choke.

    USB_VBUS(Y2) pin is connected to the USB connector VBUS trough a 47k resistor and it is connected to ground trough a  10k resistor .

    USB_DRVVBUS(T4), USB_RCALIB(V5),USB_ID(V6) are left unconnected. 

    Regards

    Roberto

  • 0 in reply to Roberto Masi
    TI__Expert 4015 points

    I have a couple of comments on the HW differences:

    1) USB_VBUS(Y2) pin should be connected to the USB connector VBUS (5 volts) through a 20K resistor, and to ground through a 10K resistor.  On your custom board, the voltage at pin Y2 is too low.

    2) USB_RCALIB must be connected to ground through a 500 +/-0.1% resistor, though the fact that it's not connected on your custom board may not be the cause of your problem. 

    3) You say you are using a type-A connector on your custom board.  Could you clarify: is it a type-A receptacle or plug?  What sort of cable are you using to connect to the host PC?

    4) What is the full part number for your common mode choke?

    I recommend first changing the pull-up resistor on VBUS to 20K.

    Regards,

    Zack

  • 0 in reply to z
    Prodigy 70 points

    Hi Zack,

    I think I found the root cause: It was the common mode choke it was too strong. 

    Bypassing it the comunication worked. 

    Many Thanks 

    Regards 

    Roberto