i.MX28: GPIO + MOSFET.

[EgleTeam]

Hi,

We have custom modules based in i.MX287 in SODIMM200 form factor. In all our base boards we've used the following N mosfet to drive different ICs:

http://www.irf.com/product-info/datasheets/data/irlml6346pbf.pdf

Now we've developed a new design placing all the hardware (processors + RAM + all components) in the same PCB. The problem we have is that with this board the GPIOs are not able to drive this mosfet. With a load  aprox. of 200mA when we try to turn on any mosfet the processor goes to reset or hang. It's as the PMU would stop working because the VDDIO rail is not able to drive the charge of the gate. We thought that in that case only the pin involved would be affected but is not the case....

We've tried to increase the value of the series resistor in the gate but in this case we can turn-on the mosfets right (processor also works right) but we can't turn-off them.

Does anyone know what is the max capacitance that the GPIOs can drive?

Thanks,

Manuel.

[Yuri · Accepted solution]

As for “the max capacitance that the GPIOs can drive” :

Really the data of i.MX Datasheets specify maximum / minimum voltage levels in relation with current loads.

These current values should not be considered as maximum allowed ones, just as reasonable.

IBIS model provides current-voltage curves for pins in order to calculate real currents

and voltages on pins.

Another case, that corresponding voltage (high, low) levels may not be in ranges, shown in

Datasheet and defined as logical “0” or “1”. 

Maximum current values are not specified, because they are application dependent and relate to general

thermal estimations. For example, if a separate pin can sink high current, say greater than 8 mA, this does

not mean that all pins may be loaded (simultaneously) with such values.

[EgleTeam]

Yurin,

We've returned to test the prototypes and I must confess that we're really baffled. It's clear that we have a serious issue in the 3.3V rail but we can't find from where comes it. Most of the pins in the 3.3V domain work right, however other like GPIOs for driving mosfets and PWMs make the processor to go to reset or hang. We don't rule PDN failure or even a defective manufacturing/assembly since different prototypes fail in different points.

Best regards,

Manuel.

[EgleTeam]

Mistery solved: some components in SOT233 & SOT235 were damaged. I informed to my assembly house because is quite annoying to losing time looking for a mistake that is not yours.

Best regards,

Manuel.

[MarekVasut]

Did you try adjusting the VDDIO rail brownout, voltage etc. in bootlets/u-boot code? It might be worth frobbing with it a bit, that might solve the issues.

[EgleTeam]

Thanks Marek,

the BO reset is set by default at the lowest value: 175mV below the trigger, 3.3V in this case, according to the source code and 350mV according to the reference manual (one of the two must to be wrong). As it  is not a big margin, we have deactivated the BO reset. Unfortunately still happening the same. Also unfortunately I didn't fanout the JTAG port so it's very difficult to debug: really a big mistake from my part.

I will replace tomorrow the 350pF mosfets for others of 50pF of gate capacitance. If the issue don't disappear then I guess the issue will be in the rounting: ringing or something like that.

Regards,

Manuel.

l.