i.MX53 Serial Downloader through UART work intermittently

[ericmar81]

Hi Experts,

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?

Thanks.

Regards,

Eric Mar

[Yuri]

   According to the Reference Manual :

---

     NOTE

ROM polls activity on all UART ports.When activity is

detected on one of these ports, ROM starts waiting for data on

this particular port and never goes to another port. UART pads

can be muxed with different devices, therefore board design

should take this into account and don’t connect to UART RX

pads devices that can drive these pads during boot.

---

  To analyze what UART is involved in boot process it is needed

to connect a JTAG debugger – to check what UART port is under polling.

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[ericmar81]

Hi Yuri,

Thanks for your reply.

There are 2 boards in my product, Board 1 (Control board) is with a Coldfire processor which acts as a host and sending the boot codes to the Board 2 (Display board) which has the iMX53 processor as the co-processor for handling graphic display. Sometimes the iMX53 is not responding to the GetStatus query form Board 1, which then fails the process to download the boot codes from Board 1 to Board 2.

Below is a screenshot of the UART communication captured between the 2 processors.

The GetStatus command is by sending: 05 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00, right? Does this look correct?

I am now bypassing Board 1 (Coldfire processor) and trying to use the PC to communicate with the iMX53 processor on my board.

I am using the uCon program to send the GetStatus command to the iMX53 and I do get a response most of the time but the waveform does not look the same as above.

Thanks.

Eric

[Yuri]

  Perhaps the mentioned restriction - "board design should take this into account and
don’t connect to [other] UART RX pads devices that can drive these pads during boot" -

affects boot process.

Regards,

Yuri.

[ericmar81]

Hi Yuri,

I had tried to disconnect all the other UART RX connections but the issue still persist.

By the way, do you know how long does it take for the MC34708 PMIC to be ready to supply for the iMX53 before we should actually try to communicate with the iMX53 through UART for Serial Downloader?

In short, how fast can we start sending GetStatus command to the iMX53 when it is powered up? Is it a right way to power cycle the PMIC to attempt multiple retries when we fail to communicate with the iMX53 upon power up?

Our current approach is: (A) System power up -> (B) Control board ready -> (C) Power up MC34708 to supply for iMX53 -> (D) Wait for 500ms -> (E) Sending GetStatus command -> (F) Power down MC34708 if not receiving response from iMX53 after 3 consecutive retries -> (G) Wait for 500ms -> (C).

Thanks & regards,

Eric Mar

[Yuri]

The time for i.MX53 boot ROM to start after reset is not specified, it depends on
clock stabilization. Waiting ~ 1- 2 sec after POR is negated is quite reasonable. 

Regards,

Yuri.

[ericmar81]

Yuri,

May I know how to check my BT_FUSE_SEL whether it is 0 or 1?

Or it does not matter if I set both my Boot_mode0 and Boot_mode1 to 1 for forcing my board to go into Serial downloader mode upon powering up?

Thanks & regards,

Eric

[Yuri]

  The BT_FUSE_SEL is unburned by default; so, the serial downloader  mode should be
actual after power on.

Regards,

Yuri.

[ericmar81]

Hi Yuri,

I think I had found the root cause for my problem.

The root cause is due to the USB_OTG_ID pin which we connect it to our onboard 5V power rail through a voltage divider network upon power up. This results in the USB_OTG_ID pin to be almost always at 2.5V upon power up. This could possibly cause the iMX53 to mistakenly assume that a USB host is connected during polling on activity of UART/USB ports in Serial Downloader mode. However, we are unsure why this happen intermittently. It could be due to tolerance and slight timing shifts from board to board which is why some boards are working fine and some are not.

Anyway, may I check with you if it is correct to follow the iMX53 QSB Schematic to route the External 5V USB power from the USB Type-B device connector's pin #1 to the USB_OTG_VBUS and the source for the voltage divider that connects the USB_OTG_ID pin?

Besides, how about the VBUS pin of the MC34708 PMIC? Do we also need to connect the External 5V USB power to this pin?

Thanks & regards,

Eric

[Yuri]

  I remember the similar issue with non-stable boot of the i.MX53,
when OTG_ID state influence was observed. But i.MX53 boot ROM
does not check the ID pin.

  As for the (USB signals) schematic. There is no reason to have pulling

resistors for the ID pin. The ID pin should either be tied to the USB connector
or be floating for device operation or tied to GND for host operation.

The state if the ID pin does not really matter for the USB controller. It serves
only for software to detect what mode the controller must operate in.

The low pass filter (100 Ohm, 1 uF) is needed to protect the USB PHY from fast
rising VBUS edges.

Regards,

Yuri

[ericmar81]

Yuri,

1. What should we do with the unused UART ports to avoid affecting boot process? Do we leave the Receiver pin of unused UART ports floating or Pull High/Low?

2. How do we know when the iMX53 is connected and ready to be downloaded?

Thanks & regards,

Eric

[ericmar81]

I would also like to find out if the Automatic baud rate detection is enabled by default upon powering up and before bootloader is downloaded into the iMX53 processor.

Was wondering if my problem could also be possibly caused by baud rate mismatch.

Appreciate if anyone can help! Thank you.

[Yuri]

Table 7-42 (UART Communication Parameters) of i.MX53 Reference Manual provides UART
parameters for the serial bootloade (fixed speed of 115200).
Table 7-43 (UART IOMUX Pin Configuration) describes  pin configurations for the UART boot.

Regards,

Yuri.