Actions
Forum Thread Details
  • State Not Answered
  • Replies 8 replies
  • Subscribers 176 subscribers
  • Views 275 views
  • Users 0 members are here
Related

Rev B/C MicroZed Errata

bhfletcher

Avnet will be publishing an errata for the Rev B and Rev C MicroZed assemblies.

PLEASE NOTE: This does NOT affect operating the board in standalone mode. The issues were discovered as we were finalizing testing of the I/O Carrier. If you have already built up your own Carrier or are duplicating MicroZed on your own chip-down design, please be aware of the following issues.

  1.   Silicon Labs CP2104 USB-UART device Vbus cannot exceed Vdd by 3.6V or more (unfortunately, this is not currently documented in the CP2104 datasheet). Since MicroZed was designed in self-powered mode (internal CP2104 regulator bypassed), it is possible that a MicroZed could be plugged into a Carrier, with a USB-UART cable plugged in, and the Carrier powered-down. The USB-UART Vbus will be ~5V in this case, while Vdd (tied to the MicroZed 3.3V rail) will be floating. This causes the part to latch up, and we have seen cases where the internal regulator will power up and start regulating 3.35V back onto the MicroZed 3.3V rail. Eventually, the CP2104 will fail in this mode.
       
  2.   The Marvell 88E1512 Ethernet PHY includes a couple LED control signals. These control signals are driven from the Vddo pins of the PHY, which on MicroZed are tied to 1.8V. We connected these control signals to the Bel Fuse RJ45 with integrated LEDs, and then we biased those LEDs with 3.3V. In the case where a Carrier signals the MicroZed to power down, the 1.8V rail will go down before 3.3V if the USB-UART cable is plugged in. While the 1.8V rail is down and the 3.3V rail is still up, leakage could occur from the 3.3V rail, through the Ethernet LEDs, into the PHY, and onto the 1.8V rail.
  •   Work-around for Rev B and Rev C – In both cases, the issue can be completely avoided by unplugging the USB-UART cable. In standalone mode, this is the only means of powering down the board, which is why this is not an issue in standalone mode. In SOM/Carrier mode, the user must unplug their USB-UART cable first before powering down the Carrier. If you don’t, you will find that the MicroZed does not fully power down and you may eventually damage your board. We will continue to sell the Rev C MicroZed boards as evaluation kits to be used in standalone mode, and we plan to provide a warning inside the Carrier kits when we start to ship them related to usage with Rev B/C. Engineers going to production with the MicroZed SOM should wait for the updated MicroZed, which we expect mid-November.

Bryan

  • 0

    Can you describes the modifications made to the schematic of the Rev D that fix the issues ? Is there a way to modify the Rev C hardware to implement the fix ?

  • 0 in reply to Former Member

    The primary cause of the issue stems from MicroZed's ability to be powered either from the USB-UART port or a Carrier. When you power off the Carrier and quit supplying Vin power to the MicroZed and disable the regulators, you would expect power to shut off. Unfortunately, we found that half the regulators were staying on because they still had a supply voltage (USB-UART Vbus) and because of leakage paths (through the CP2104 and the RJ45 LED circuit) that allowed enable signals to drift high.

     

    My point is that if you eliminate power at the USB-UART, you don't have a problem. The work-around with a Rev B or Rev C plugged into a Carrier is that you have to unplug the USB-UART cable before you power down the Carrier.

     

    The next revision will actually be a Rev F (we had intermediate internal releases of D and E that never got built). Rev F fixes the two leakage path problems:

    •   The CP2104 circuit was redesigned from self-powered mode on Rev B/C to bus-powered mode on Rev F. This prevents Vbus from ever exceeding Vdd by >3.6V, which is what was leaking in the Carrier powered down mode.
    •   The RJ45 LED Circuit was redesigned to add some control FETs to isolate the 1.8V control rail from the 3.3V LED power rail.

    I do not think it is reasonable to rework a board with these changes. The alternative of simply unplugging the USB-UART cable is a much easier work-around until you can get Rev F.

    As soon as I can get a final copy of Rev F, I will publish it so you can see what we did.

    Bryan

  • 0 in reply to bhfletcher

    Many thanks for your detailed explanation.

    I don't car about the RJ45 LED so I can simply remove R65 and R66 to cut the current path trough them.

    I found more annoying the CP2104 problem as the USB console is really required to develop and having to manipulate the cable for each power cycle is out of question when you are not close to the target (remote work). Making it bus powered is a good idea anyway so it don't close the connection at each power cycle. My understanding is that VDD must not be connected to 3.3V but only to C9 and C6 and that REGIN must be connected to VBUS. Unfortunately the REGIN on pin 7 and the VDD on pin 6 are routed to a via that is partially hidden under the CP2041 chip. Cutting the route to it should be doable with high skill and motivation. Note about the routing: the power should be routed on the top layer up to the decoupling capacitors and only then go on a via if needed. This make the decoupling more effective and would have made the rework more simple in this particular case.

  • 0 in reply to Former Member

    I agree that the CP2104 rework is difficult. You are correct that to accomplish it you need to:

    1.   Disconnect U2.pin7 from 3.3V. Connect to net USB_VBUS_UART, which is accessible on U2.pin8.
    2.   Disconnect U2.pin6 from 3.3V, while maintaining connection to C9 and C6.

    Be aware that if you rework a board, you do so at your own risk. This is why I am recommending that people work around this by simply removing the USB-UART cable when in a Carrier powered-down situation. That works around both the RJ45 LED and CP2104 issues. I understand that is not an acceptable requirement for a product, assuming you are designing MicroZed into your product as a SOM. But for prototyping it might be acceptable. And we will have updated boards as quickly as possible.

     

    Obviously, we are also frustrated with the issue, especially since the self-powered configuration is perfectly acceptable according to the CP2104 documentation with no mention that Vdd cannot be powered down. We are working with Silicon Labs to get that changed in their documentation.

     

    Bryan

  • 0 in reply to bhfletcher

    Thanks Bryan for your information.

    You can find the picture of the rework on this link:

    http://www.eclis.ch/zedboard

    The CP2104 is now bus powered and it's a very useful modification for me.

    Jean-Christian

  • 0 in reply to bhfletcher

    We had SiLabs review our updated design, which prompted one more rework instruction here. The current rework becomes a problem when you power on the board but the cable is not plugged in since VIO will be active and Vdd/Vbus will not. In order to mitigate this situation, we have added a diode between 3.3V and Vdd such that 3.3V will power Vdd when Vbus is off.

     

    Bryan

  • 0 in reply to bhfletcher

    Many thanks Bryan for your update information. I will add the diode too.

    I hope that one day, SiLab, FTDI and the others will provides USB/UART converter chips that don't require fixed powering mode, but automatically switch between VUSB and VDD depending of there availability. 

  • 0

    Hi Experts,
    Recently, we bought 2 number of microzed evaluation kits.
    Could you please tell me how I find what revision we are using.
    "Z7MB-7Z0X0-PCB-F" is written under the board.
    I think it is revision F.
    Also I find the Zynq SOC chip is quite hot.
    Is it normal?
    Regards
    Mahdi,