A20-SOM battery charging and powering peripherals

[vveloso]

Hello,

I'm evaluating the A20-SOM for an embedded application with an LTE modem that must be able to run off a battery in emergency situations and for low-power monitoring (i.e., SOM off or in suspend mode and LTE in minimal service mode).

Hence my questions:

• Does the A20-SOM require an external battery charger, or will it manage charge of the battery once it is connected?
• Can the A20-SOM be in low-power suspend mode (or off) and yet still provide 3.3V through the GPIO?
• How much current can one draw from the 3.3V lines through the GPIO? I see that the DC/DC converters are rated at 1.6A; would I be able to continuously draw 1.2A or 1.4A maximum?

I searched the forums, saw quite a number of problems but no solutions. Nor any workarounds. 

Thank you! 

Vasco

[JohnS]

That may very well mean that no-one read the datasheets - did you?
(or that they do not say)

I would say your mix of issues is unique.

John

[vveloso]

That may very well mean that no-one read the datasheets - did you?
(or that they do not say)

OK John, thanks for you reply. I'll bite. I did. Let me rephrase and be more specific:

• The PMIC in use is the AXP209, which can control battery charging IIF enabled in register 33h and configured in register 34h. How is the AXP209 configured by default in the A20-SOM with the official Linux build?
• A20 supports standby mode. According to linux-sunxi, the suspend-to-ram function is limited in the sense that it suspends but discards RAM contents in the subsequent boot (it is therefore a clean boot). A clean boot is acceptable for my project as long as it suspends. Does the official Linux distribution support suspending the CPU? I'd say it does from statements found elsewhere but I'd appreciate some more comments on this matter.
• The SY8009 DC-DC regulator in package SOT23-5 is rated to 1.5A. Since I don't really know how much current the CPU and SD card use off this rail (the CPU should also draw current from 1.5V and 1.2V rails), how much would be available for GPIO and would be sustainable given the PCB thermal and load characteristics?
• The 3.3V regulator is controlled by AXP209s' EXTEN signal, which is in turn controlled in its 12h register. Does the official Linux distribution keep this enabled during suspend?

I would say your mix of issues is unique.

We are all unique individuals and so are our projects.

Vasco

[JohnS]

For such specific things, read the source - being Linux you actually can!

John

[soenke]

I cant help you with 1,2,4.

But concerning GPIO-Power i can tell you that drawing 8mA on 60 GPIOs at once while having heavy CPU load works perfectly fine.

But 1.5A... i think that would be too much current through the CPU. For sure you will need a heat sink and maybe also on the PMIC

You should think about adding some mosfets/SSRs between the CPU and your load to get the current on a more direct way to where it is needed.

[vveloso]

I cant help you with 1,2,4.

But concerning GPIO-Power i can tell you that drawing 8mA on 60 GPIOs at once while having heavy CPU load works perfectly fine.

But 1.5A... i think that would be too much current through the CPU. For sure you will need a heat sink and maybe also on the PMIC

You should think about adding some mosfets/SSRs between the CPU and your load to get the current on a more direct way to where it is needed.

Hi soenke,

I see that I didn't make myself clear.    What I meant was to draw power from the 3.3V pin on the GPIO header, not from the processor IO pins.

Cheers!

[soenke]

Ok, now i got it
I would just try it out by slowly increasing the load on one of the 3.3V-pins and watch the VREG temperature and the voltage very closely. I dont think anybody (maybe exept olimex) tested the 3.3V-rail to its limits.