Reading the Intel® Edison Compute Module Hardware Guide I understand you should connect VSYS to a 3.3V - 4.5V voltage source. Connect DCIN to VSYS. PWRBTN# is an input, and it should connect to VSYS in the same way showed in Intel® Edison Breakout Board Schematic (pdf), page 7. RESET_OUT# is an output to indicate a system reset.
That is my interpretation about the info in the documentation, do you have the same interpretation or another one?
I think you just treat DCIN as a signal to tell Edison that there's a DC power supply connected.
If you leave DCIN floating (I assume it's pulled down) and the voltage on Vsys is below 3.5V, it assumes that the battery attached to it is flat (3.5V with a small load is pretty much completely flat for a single LiPo cell) and aborts the boot sequence. Presumably if it doesn't rise from 2.5V to 3.5V in 10ms then that implies a substantial resistance in the supply wires, which is also a good reason to stop booting.
If you tie DCIN high (ie to Vsys) then you're telling it "this is a power supply". This means that Edison doesn't care if the supply appears to be "flat", and it doesn't impose a limitation on the supply rise time (power supplies with big output capacitors can take a while to reach the right voltage).
Having Vsys and DCIN separated by the power outputs is a bit annoying (hard to connect them together). I've ended up ignoring the Edison voltage outputs and putting my own 1.8V regulator elsewhere on the board.
Thank you, @Slayte and @Diego_Intel. I'm starting to come around to understand that
DCIN floating or low = "battery attached: don't boot if it's flat"
DCIN pulled to VSYS = "Power supply attached or ignore battery".
I sort of read the documents the same way. But I have two problems with this (besides the fact that the documentation doesn't read very clear to me):
1. I am tying DCIN to VSYS in the custom Edison "block" I mention in the other thread. But my Edison doesn't seem to boot when I attach a fully charged battery. This same Edison does boot when attached to either USB-powered breakout. Perhaps there is something else wrong with my board. I'll keep investigating.
2. The SparkFun people seem to be tying DCIN to VSYS in all their blocks, including the "battery block". If it's important to signal to Edison that there is a (possibly dying) battery attached, why don't the SparkFun people do it?
What is the benefit of telling Edison "please don't boot if this battery is flat" anyway?
(1) That is very odd. I can't see any reason why a fully charged battery (I assume this is a 1S LiPo) wouldn't work when USB does. I assume you've connected the power/reset pins the same as on the Sparkfun boards?
(2) For hobbyists it probably makes more sense to just boot regardless of the voltage and assume that the user knows what they're doing (some might be using LiFe batteries or a couple of NiMH ones). Better than dealing with all the support requests for "Edison won't boot" that turn out to be because the battery isn't a LiPo, or because they're just running it off a 3.3V power supply, etc. I guess there's a potential for problems to occur if it loses power during boot, but that could happen when run from a power supply too.
I suspect that this is "the power management chip supports this feature so we might as well have a pin for it" more than anything else.
Thanks Slatye. I hope to get a pre-release SparkFun console block soon. I'll use that to examine the boot spew (if any) and hopefully get to the root of the problem.
> I assume you've connected the power/reset pins the same...
Well, not the resetout# pin because DiegoV_Intel said that was an output-only pin? I guess I'll try wiring it up like SparkFun does to see if it makes any difference. Thanks!
I just thought I'd make a happy update to this ancient post.
Just to recap, back in November I created my own Sparkfun-esque Edison GPS "block", but when I attached it to my Edison and applied power, it didn't boot. So it sat on the shelf for 11 months. Recently I got it back down and had a little "eureka!" moment. I now know why it doesn't boot, and I have fixed it!
Here's what happened. I had routed the GPS RX signals through UART2 a.k.a. /dev/ttyMFD2. That's the serial port we know as the "console", or "kernel spew" port. I was thinking that since the kernel spew goes in one direction (TX) and the GPS stream goes in the other (RX), I could use the same port for both. The problem is that there's one point early in the boot process where it invites the user to "press any key to abort boot...", and of course the GPS stream triggers this boot abort. I cut the UART2 traces to my board and reattached the GPS to UART1, and now it boots beautifully. Very happy!
Many thanks to the Sparkfun "base" block for allowing me to finally figure this out!