iMX8mm UUU flash fails, sometimes

[EmbeddedN00b]

Hi all!

Im working to trying to solve a problem that one customer currently have:

The flashing of the custom made board fails, Sometimes.

We have a production line where our custom boards with Imx8mm is programmed using UUU, and for some unknown reason around 10% of boards are failing during flash:

As we can see in the screenshots above(log output from our end-of-line tool), the problem seems to be related to the USB connection.

The EOL computer is running windows 10, with the latest updates(as week 38). We have a USB 1.1(To force a slow down of the USB transfer speed) hub between the  computer and the boards.

We are running UUU version 1.5.21.

The interesting part here is that the EOL tool that starts the uuu.exe has a retry-case, that is retrying the flash/ UUU operation one more time upon failure, and what we have seen is that the second try(without any power-cycle of the board) always works/passes

I have checked in the Windows event logger to see If there are any errors related to USB there, but I can't find anything there.

Does anyone have any idea on where to look?

The uuu flash script:

uuu_version 1.5.21
SDP: boot -f imx-boot-sd.bin-flash_evk

SDPV: delay 1000
SDPV: write -f imx-boot-sd.bin-flash_evk -skipspl
SDPV: jump

FB: ucmd fuse prog -y 1 3 0x10002223

FB: ucmd setenv ip_dyn no
FB: ucmd setenv ipaddr 192.168.1.1
FB: ucmd setenv serverip 192.168.1.2
FB: ucmd setenv netmask 255.255.255.0

# TFTP download and flash bootloader
FB: ucmd setenv updatefile imx-boot-sd.bin-flash_evk
FB: ucmd setenv loadtftpimage 'echo "Trying to tftp get bootloader image ${updatefile} from ${serverip}..."; if tftpboot ${updatefile}; then echo "Downloaded TFTP bootloader image ${updatefile}. Writing to mmc..."; setexpr cnt ${filesize} / 0x200; setexpr cnt ${cnt} + 1; mmc dev ${mmcdev} 1; mmc write ${loadaddr} 42 ${cnt}; mmc rescan; fi;'
FB[-t 10000]: ucmd run loadtftpimage
...
env default -a && reset
FB: done

[Chavira]

Hi @EmbeddedN00b !

Thank you for contacting NXP Support!

Try to delete the uuu.exe and download it again.

I don´t know if your USB Hub can be the problem.

Please try to connect directly the boards to the Host or use a USB 2.0 Hub.

The 2 errors on your logs are related to USB devices.

"Failure open USB device", "LIBUSB_ERROR_TIMEOUT"

If the problem persists please try to use another PC or using Linux to discard Windows failures

Best Regards!

Chavira

[EmbeddedN00b]

Hello Chavira!

Thank you for your reply!

I will investigate possibilities to connect directly to the board, but the history has shown us that there was a lot of problems related to the high speeds during download with regular USB, and that is the reason why we have "clocked down" the speed by forcing a USB 1.1 level.

I will also investigate the possibility to change the PC, might be a bit hard as this is a running production line.

[Chavira]

Hi @EmbeddedN00b!

We have to be sure and try all the possibilities to increase the FPY in your production line.

Please try to make the changes or only change your script to do 2 or 3 attempts per board.

Best Regards!

Chavira

[EmbeddedN00b]

What is FPY?

So far in my investigation, I have seen that if I modify the UUU and increase the timeout of the libusb calls, the LIBUSB_TIMEOUT_ERROR has disappeared atleast.

But I still have the other error.

Retrying the procedure seems to be helping in 98% of the cases, sometimes I need to retry a third time.

[sbmd_1234]

Hi
I am also getting the LIBUSB_ERROR_TIMEOUT issue where you have changed the uuu for timeout?

[EmbeddedN00b]

Hello sbmd_1234!

I modified the libuuu/cmd.h file:

In the class CmdBase, there is a protected integer m_timeout, where the default value is 2000, but in my case I have updated it to 25000 instead to reduce the problems. But still we have problems, but they are way less now.

Our investigation has concluded that the problem is in Windows and how thw windows usb driver handles the reoccuring USB connect/disconnect that happends during the SW download.