We uses the i.MX53 Serial Downloader to load u-boot over one of the UART ports. However, we are unable to initiate the communication with the i.MX53 processor sometimes, and thus, unable to load the u-boot over the UART port. This happens intermittently. There is no response when we issue a command to the i.MX53.
Boot_Mode0 and Boot_Mode1 pins are tied to High for using Serial Downloader boot mode. The USB OTG port is connected to a USB type B connector but not connecting to any host while booting.
UART-1 is being used as the UART port to download the u-boot, whereas UART-3, UART-4, and UART-5 are left floating.
There was a mistake which we connected the UART-2 Rx pin to the SDWNB (open drain) pin of MC34708 PMIC. We use this PMIC for powering up the i.MX53 processor. However, we cannot break the connection as the signal is laid in the internal layer of the PCB. This SDWNB pin is pulled up and thus is always High except when we trigger to reset the MC34708 PMIC.
Both UART-2 Rx and the UART-1 Rx pins are High after powered up and there is no activity seen on the UART-2 Rx pin before UART-1 Rx pin is receiving a transmission from the Host for downloading of u-boot.
However, it is unknown why sometimes we are unable to initiate communication with the i.MX53 as we issue a command to it and not receiving any response. We can see from the scope that the data are received at the UART-1 Rx pin correctly though.
Some of our questions as below:
1. Can the UART-2 Rx pin which is connected to the SDWNB pin of MC34708 PMIC the cause of this intermittent u-boot download problem?
2. Is there any way we can find out which port was listened as activity detected by the i.MX53 during the Serial downloader mode?
3. Can we fix i.MX53 to poll on just UART-1?
4. How does i.MX53 determine there is activity in any of the ports? Is it by detecting falling edge for UART ports? How about the USB OTG port?