"uuu.exe -lsusb" showing different outputs for parallel flashing (2 boards)

[ajithpv]

Hi,

I'm using i.MX8QXP custom board with UUU version(libuuu) 1.3.102 on Windows Host PC. We are using parallel flashing (i.e. 2 i.MX8QXP boards flashing at the same time) with -m option to specify the USB ports.

However, when checking the USB port (after powered ON both i.MX8QXP boards) using "uuu.exe -lsusb" command, I'm getting different outputs as listed below:

• Case 1 - Where both the boards are listed with identical output:

 Path     Chip     Pro       Vid        Pid     BcdVersion 
 =========================================================
 2:2      MX8QXP   SDPS:    0x1FC9      0x012F    0x0002
 2:1      MX8QXP   SDPS:    0x1FC9      0x012F    0x0002

• Case 2 - Where both the boards are listed with different output:

  Path     Chip     Pro       Vid        Pid     BcdVersion 
  =========================================================
  2:2                 FB:    0x0525      0xA4A5    0x0221
  2:1      MX8QXP   SDPS:    0x1FC9      0x012F    0x0002

• Case 3 - Where only 1 board will list out as the output:

  
  Path     Chip     Pro       Vid        Pid     BcdVersion 
  =========================================================
  2:2      MX8QXP   SDPS:    0x1FC9      0x012F    0x0002

May I know which one is proper here? Also I would like to know why it is not showing consistent output?

Could you please let me know whether anyone come across this kind of reliability issues earlier? Also, possible solutions to make sure everything works fine too.

[nxpfrankli]

The order is dependent libusb return.

but PATH 2:1 \2:2 is that fixed for a specific usb physical port.

That's means you connect one board at 2:1 port, the other board at 2:2 port.

if you run uuu -m 2:1

2:2 port QXP board can't trigger download, only 2:1 port can trigger download.

-m is used very popular in our daily test because we connect difference boards at the same machine.

[nxpfrankli]

About CASE2, QXP which connect to port 2:2 is booted and uboot run fastboot.

[ajithpv]

@nxpfrankli Thank you for your valuable feedback. I would also to know whether we need to take care anything specific on the USB connection from board to PC - such as the cable length, voltage/current levels, reboot timing etc - which may cause different -lsusb output (while expecting both board flashing with SDPS protocol)?

PS: We asked the above question because we have observed the flashing got interrupted (i.e. flashing will stop in-between with or without any error) frequently when we connected a USB HUB between PC to board. When we removed the HUB, then the flashing becomes proper.

[nxpfrankli]

HUB may affect port number sequency. Avoid remove\ plug the whole USB hub. If only plug\unplug one port, it will not affect lsusb. QXP fastboot support supper 3.0 speed. But it is sometime that fail back to USB 2.0. fastboot may switch a difference logic port difference with SPDS.

uuu need monitor two difference logic port, one for 2.0, one for 3.0 mode although physical port is the same.

[ajithpv]

QXP fastboot support supper 3.0 speed. But it is sometime that fail back to USB 2.0.

I would like to know whether we should use USB 2.0 Interface?

Currently we have connected both boards on a USB 3.0 interface on the PC side. Is this causing the intermittent disconnection as QXP fast boot is not able to support USB 3.0 consistently?

[ajithpv]

About CASE2, QXP which connect to port 2:2 is booted and uboot run fastboot.

Could you please give some more hints on the above case?

What I understood that - SDPS is the protocol for flashing whereas FB (Fast Boot) is the protocol for running the U-boot. Since case 2 shows port 2:2 in FB, it means that, the board is not detected as flashing mode and is in booting mode at that time. Please correct me If I'm wrong.

Also, is there any minimum time for -lsusb to detect the SDPS or FB? We have observed sudden power OFF and ON after clearing the binaries from eMMC (to detect the SDP mode for flashing) will show FB or empty instead of SDPS in some cases.

[nxpfrankli]

SDPS is using for download uboot into board, which talk with ROM. that's means board is reset status, ROM wait for uuu to download image.

After uboot boot, uboot will run fastboot automatically. uuu talk with uboot by fastboot protocol to flash image into emmc/sd.

case 2 shows port 2:2 in FB, which means uboot already run at that board and ready accept fb command.

if power OFF and ON, it still show FB, which means board have not boot succesfully. Maybe some capacitor in board maitain status and chip is not reset totally.

[ajithpv]

Thank you @nxpfrankli .

May I know what is the sufficient time for set to the SDPS protocol?

Also, we have observed the FB protocol even in the virgin boards (i.e. the boards which are going to flash for the first time) and the observations on the USB connection were seen towards the first detection of boards.

May I know the reason for FB protocol to show on the new board? Please note that, this is coming sometimes only, in other cases, it will start flashing without any issues.

[nxpfrankli]

Actually, uuu poll usb port status about every 100ms. Theoretically, uuu always get into SPDS status.

Does reset board(or replug usb cable) help this case ? Does it happen at external hub port or pc root hub port?