imx233 weird DCDC capacitor problems


Image

We started our OSHW Linux computers with imx233 processors from Freescale. The reason was that it was cheap and possible to buy in any quantity + they came in TQFP package and are easy for DIY at home, so anyone can build his own Linux computer.

Many thousands of imx233 based OLinuXino devices are sold and work reliable in many applications, but recently we were bumped in weird problem with the imx233 DCDC.

imx233 is highly integrated SoC as it’s purpose when designed was media player, so the all internal voltages are generated with internal DCDC.

If you look at the schematic above you will see L1 with C74 C75 are used in the internal DCDC. Freescale recommends C74 and C75 to be not populated in the users manual, but we found when ran the first lot of OLinuXino that if C75 is missing the board will never start when powered by LiPo battery only. Touching the C75 pads with scope probe started the boards, so initially we decided to put there small 10 pf capacitor, with this value the boards were starting reliable if LiPo is only connected.

We all know that processors and components have tolerances, after we ran more boards we got some statistic and some of boards didn’t want to start with 10 pf, we play more than week and found that if we rise C75 to 100 pf this solve all startup problems and all boards which were failed on the test for this condition were cured with C75=100 pf

So far so good, we put 100 pf in the production manuals and continue to manufacture imx233 boards, while last week we got call from customer, who bought 50 pcs imx233-mini and some of them failed to work with USB. He did some analyze and found that the difference between boards which work and do not work use different date code USB hub chips GL850. We asked these boards back and start investigation.

When we received them we run them on our functional tests and … all they pass the test, this was weird as customer reported these to have problems. After a while we found the difference – in our tests we use ARCH linux image, while the customer was using Debian, we run Debian Linux and same boards which worked with ARCH image start to give errors ONLY in case you attach USB flash drive to the USB port!

NOW this was really weird, as with the old data code USB GL850 hubs the boards were working with both Debian and ARCH but with the new date code hub only ARCH image was working and Debian image was giving errors when USB Flash drive is attached.

We spent about week to chase this problem as it is some mix of both hardware and software issues and after a week of investigation we found the problem is caused by … C75(!) reducing C75 to 15 pf solves the USB port problems. Now this is really weird.

If C75 is lowered problems with startup of the DCDC when powered with only LiPo occur, when C75 is with higher value the DCDC becomes very sensitive to the overall power consumption and when USB flash drive is attached to some USB hubs which obviously have different power consumption due to tolerances the USB port start to give errors.

We obviously have no intern knowledge how this DCDC is implemented in imx233 and why it interference with USB ports to dig to the root of the problem, for the moment replacing the C75 solves the problems, but anyway this still is weird bug.

We can’t also understand why ARCH linux image is more immune to these problems and what is the difference between USB port initialization with ARCH and Debian images.

Any help and comments on above is welcome from people who know more🙂

 

EDIT: Here is some more information which I forgot to attach at the beginning:

this is with ARCH Linux distribution build with Kernel 2.6.35 we use when mass storage is plug in USB: http://pastie.org/9283768

this is with Debian distribution built with Kernel 3.11 when MOD-RTL8188CU is plug in USB: http://pastie.org/9283772 everything is normal

these are the error messages with same Debian distribution when USB flash drive is plug in: http://pastie.org/9283780

 

EDIT2: This issue only happens when hub is connected to imx233 USB host – either GL850 either LAN9512, the issue do not happens on Micro and Nano where there is no hub between imx233 host and USB mass storage.

17 Comments (+add yours?)

  1. xxiao
    Jun 12, 2014 @ 15:00:32

    does ARCH and Debian run the same kernel, as the USB related driver might be different. I would look into and compare the drivers and see what’s the diff. Also check if there is an errata on usb from imx233 but I guess you did that part.

    Reply

  2. Evgeny
    Jun 12, 2014 @ 16:30:38

    Could you please specify what exactly were these “errors” and “problems”?

    Reply

  3. Scott
    Jun 12, 2014 @ 16:36:22

    there is a fair bit of info in the reference manual about the power supply area however i didn’t read through it in great detail.

    with this sort of issue i usually go to the errata as it often has bugs in the silicon listed. there are a few around the DCDC
    http://cache.freescale.com/files/dsp/doc/errata/IMX23CE.pdf?fr=gdc&Parent_nodeId=1248908948248708103376&Parent_pageType=product

    if this didn’t find the problem i usually email an application engineer at freescale, at the volumes your purchasing in they are usually happy to help.

    good luck

    Reply

  4. OLIMEX Ltd
    Jun 12, 2014 @ 17:27:43

    I just add pastie information about the error messages we get, also ARCH is with Kernel 2.6.35 but Debian is with Kernel 3.11

    Reply

  5. NU8
    Jun 12, 2014 @ 22:56:50

    You said, it is related to overall power consumption. Do both the Debian ang the ARCH system comsume the same amount of power? I would expect Debian to consume more.

    Reply

  6. Bert
    Jun 13, 2014 @ 13:30:01

    I described DCDC problems with imx233 a monthes ago. https://www.olimex.com/forum/index.php?topic=2257.0

    Reply

  7. Cyk
    Jun 13, 2014 @ 17:09:42

    I’d bet that this problem is related to a bad layout leading to an EMC problem.
    The DC/DC runs unstable and produces EMI, that interferes with the USB port in certain conditions. Try different components (L,C) of high quality and of course a better layout.

    Reply

  8. Kari
    Jun 16, 2014 @ 11:27:25

    Hi!

    Have checked that both Linux versions programs same parameters to processor internal DC/DC converter?

    BR Kari

    Reply

  9. Darius
    Jun 16, 2014 @ 16:03:17

    We have similar problem, but board with c75 100p, will stop working after some file transfering via ethernet link. We will remove c75, then board working stable. (we not using batery). I think that problem is that 5v power. I tested board with additional tantal capacitor 10uF on 5V and have board stable with c75 100p.

    Reply

  10. Darius
    Jun 17, 2014 @ 09:28:46

    My notes for board imx266 Olinuxino maxi rev. C2:
    1. Strange “Reset circuit” – it from freescale example- but one important differences: is not capacitor between base of T2 and ground. Layout from R9 until T2 base very long ( anthena effect ). So this place very danger for stability. To resolve- need add capacitor on base (like original freescale example) and R9 move to near T2. Maybe better need remove “reset circuit”.
    2. XTAL Q1 (24Mhz) and it capacitors, “reset circuit” mus have self ground, other grounds (exmpl. cpu power ground) must be connect to cpu from other side. This is standart recommendation of cpu layout.
    3. Freescale L1-have 15uH value, your board 22uH. Capacitor C82 (C75) need remove, if not used batery. Solution with C82 (C75) – don’t like for me – it increase power current. Maybe problem quality of L1 or value.
    Freescale recommendations “The i.MX233 should use ceramics + 100 mOhm series resistors or low-ESR tantalums for both the VDD4P2 and the LI-ION BATTERY supplies to prevent a battery charger oscillation issue.”
    4. Need add additional 10uF tantalum capacitor on 5V power. TO Do better layout off power dc/dc stabilizators.
    5. DRAMM power decoupling capacitors have only one via – to ground. Need do 4 or more.

    Reply

  11. Darius
    Jun 17, 2014 @ 10:43:53

    Additional note:
    Some maxi board was very unstable. Problem was, that very small xtal Q1 oscilation amplitude. Possible bad quality of oscilators. Problem was resolved by replaced Q1 oscilator.

    Reply

  12. Pavel Kamaev
    Jun 18, 2014 @ 00:39:32

    When this chip just powered up it uses internal LDO’s. After that you switch to second DC-DC (which works through inductor, can’t remember correct name). At this moment voltage drops and at my board brownout was detected (3.3V dropped too low).

    Try disabling brownout detection on this line (there was #define in power_prep.c if you using it).

    Reply

  13. Trackback: Linux boote!!! | librecalc
  14. iafo1
    Nov 05, 2015 @ 20:39:59

    I also have an issue with my imx233 MAXI:
    I run on it a software which continuosly acquires data from a USB-RS232 converter connected to it. The same software works well with an imx233-mini-wifi but on the MAXI it stops acquiring data after a while (lets say 1h). May my problem be related to the same issue? If I remove the capacitor C75 maybe I fix it?
    Thank you!

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: