search

Pinoccio / hardware-pinoccio

The schematics, board layout, and datasheets for the Pinoccio board
Other
55 stars 27 forks source link

Scout v1.1 hardware revision #11

Open amcjen opened 9 years ago

amcjen commented 9 years ago
jingman commented 9 years ago

If there's a way to make it so that the scout does not reset when connected/disconnected from USB power, that would be awesome.

eeintech commented 9 years ago

@jingman: see #5

@erictj What is U2 load-switch function? It seems like it is use in a diode fashion and add some redundancy to D3. I have removed it to from one my scout after I shorted U2 out to Ground (don't ask me how...) and just have the diode now, the circuit and scout performs similarly.

matthijskooijman commented 9 years ago

Eric and I just had a long talk over hardware issues, and a new proposal is to let the 16u2 be powered off regular VCC instead of VUSB, preventing it from powering down (instead, it will sleep when USB is not connected). This prevents issues with draining power (#4) but also allows fixing #5 and #6 by doing the reset pulse in software instead of hardware.

For detecting VUSB, this needs a voltage divider (5V -> 3.3V) connected to a pin on both the 16u2 and the rfr2 (it seems the 16u2 does not have any internal way to tell wether VBUS is applied).

eeintech commented 9 years ago

Has anyone investigated the oscillations on the output of the MCP73832 battery IC charger when battery is disconnected and USB power plugged in? It also makes the yellow charging LED to flash.

amcjen commented 9 years ago

What is U2 load-switch function? It seems like it is use in a diode fashion and add some redundancy to D3. I have removed it to from one my scout after I shorted U2 out to Ground (don't ask me how...) and just have the diode now, the circuit and scout performs similarly.

This load-switch was required to solve this issue. The load switch is there to minimize leakage between VBAT and VUSB when no USB power is plugged in. The diode was required because of the strange issue with the blog post above.

When you sizzled your load switch, did you just connect the in and out of the load switch to power the scout while USB is plugged in? Looks like it wouldn't power up otherwise b/c the PFET will disconnect upon USB power?

amcjen commented 9 years ago

Has anyone investigated the oscillations on the output of the MCP73832 battery IC charger when battery is disconnected and USB power plugged in? It also makes the yellow charging LED to flash.

I did during the initial board design. I believe a 100µF cap minimum is required across VBAT/GND (or the +/- through-holes underneath the battery JST jack) of the battery when running without any battery attached. I think this is in the 73832 datasheet, but decided to leave it off b/c 100µF caps are big, and we weren't going to sell Scouts w/o a battery. A cap should solve it though!

amcjen commented 9 years ago

@blathijs @Cisco25 Here is a first pass at the next revision of the board. It covers most (but not all) of the changes listed above. Mind having a quick review to see if it's close? (Still need to add the bias connection for the RF FEM.)

pinoccio v1 1-1 pinoccio v1 1-2 pinoccio v1 1-3

eeintech commented 9 years ago

Few questions:

I noticed that SEROPN (= Serial open signal?) is present on the RFR2 PG5 pin but the signal does not show on any of the 16U2 pin, you might want to make sure it connects.

This load-switch was required to solve this issue. The load switch is there to minimize leakage between VBAT and VUSB when no USB power is plugged in. The diode was required because of the strange issue with the blog post above.

When you sizzled your load switch, did you just connect the in and out of the load switch to power the scout while USB is plugged in? Looks like it wouldn't power up otherwise b/c the PFET will disconnect upon USB power?

Now I remember reading about that load-switch issue. On my board I completely removed the switch and actually even replaced the schottky with my "own" 1A schottky diode. I don't remember having any issue to switch between USB and Battery power but I will double check if the PFET issue happens and doesn't allow full battery voltage on the LDO input.

I did during the initial board design. I believe a 100µF cap minimum is required across VBAT/GND (or the +/- through-holes underneath the battery JST jack) of the battery when running without any battery attached. I think this is in the 73832 datasheet, but decided to leave it off b/c 100µF caps are big, and we weren't going to sell Scouts w/o a battery. A cap should solve it though!

Understood, just making sure that item was known.

matthijskooijman commented 9 years ago

16u2 power: I believe UCAP is the output of the 16U2 internal regulator that you use to supply VCC/AVCC, so it's seems weird to me that UVCC is not connected to VBAT instead, could you explain how does that work?

The power connections are made according to the 16u2 datasheet. See "USB Module Powering Options" under "USB Controller". This is the "Typical Self powered application with 3.0V to 3.6 I/O" on page 188.

AFAICS the internal regulator needs 4V+ to operate, so instead of using the regulator, we just supply a regulated 3.3V directly. Not sure why UVCC is still connected though, but the datasheet also says the internal regulator should be disabled in software.

It does seem that the VCC ->16u2's VCC is missing, or at least not clear from the schematic. I guess renaming the UCAP net to 16U2_VCC, or perhaps just merge it with the existing VCC net also makes sense?

16u2 reset: did you remove the 2k resistor to rely just on the internal pull-up?

Good point, I think the pullup should stay, there's no reason to remove it (perhaps you confused it with the rfr2 pullup in your notes, Eric?).

ADC-IN to Ax: it seems like you'r counting on users to input 0-3.3V signals on the ADCs, which ends up with 0-1.5V on the RFR2 pin, I remember being able to measure as high as ~1.7V until it reached 1023 but the current circuit would not let you do this, correct? I would also advise for a small cap (10nF) in parallel with the 100k resistors to stabilize the input signal.

Hm, doesn't the rfr2 offer an 1.5V reference voltage as well? It would be best if could cleanly map 3.3V onto one of the available AREFS.

I noticed that SEROPN (= Serial open signal?) is present on the RFR2 PG5 pin but the signal does not show on any of the 16U2 pin, you might want to make sure it connects.

I suspect it's connected to pin 12, but the label is hidden on the 16u2 side.

Some remarks of my own:

I just realized a big downside of these voltage dividers: They'll mess up the input voltage when using the pins as digital pins, making these pins effectively analog-only. I think this is a show-stopper - as someone on the forums pointed out, a lead scout would only be left with two digital pins if you cannot use the analog pins for digital I/O as well.

Having toggle-able resistor dividers would solve this, but then we'd need to have one extra I/O pin for each analog input (or an SPI-controlled expander / shift register), so I'm not sure how we can make that work...

So, perhaps somehow add a 1.8V source or something like that?

It seems that the yellow led is supposed to indicate USB power. It is connected to UCAP before, but that doesn't work anymore now. I guess it should just connect to VUSB directly (and have its resistor modified)? Or, looking more closely, it seems it indicates "charging", not "usb connected". Does the charger IC drive its STAT pin high when no VUSB is present? If so, the led can probably stay as-is.

You should probably rename the RESET_EN net (perhaps to RST, to match the label on the pin header?). The name seems to originate from the Uno design, which actually has a solder bridge to enable/disable auto-reset (hence "reset enable"), but I've found it confusing when looking at the schematic.

I think the VUSB_IN resistor divider is connected wrongly? It will put 5V on the IO pin now?

eeintech commented 9 years ago

It does seem that the VCC ->16u2's VCC is missing, or at least not clear from the schematic. I guess renaming the UCAP net to 16U2_VCC, or perhaps just merge it with the existing VCC net also makes sense?

This is what's missing in this schematic, there is currently no input power source. VCC power should be tied to 16u2 U/Vcc/Vcc/AVcc pins else 16U2 would not get power.

I just realized a big downside of these voltage dividers: They'll mess up the input voltage when using the pins as digital pins, making these pins effectively analog-only. I think this is a show-stopper - as someone on the forums pointed out, a lead scout would only be left with two digital pins if you cannot use the analog pins for digital I/O as well.

Just throwing that idea out: using a dedicated ADC chip like the ADS7828 (in smaller form factor maybe) that can give you a full range between 0 and 3.3V. That way you free up 8 digital pins... but not sure where you could map those extra pins to.

matthijskooijman commented 9 years ago

Eric and I just had another meeting. Eric just made a few more changes:

I think that was all the clear-cut comments, or are you missing anything @Cisco25?

Regarding the ADC - adding an extra ADC doesn't really solve the problem, then you still can't use the pins as digital (unless you connect them to both the rfr2 and the ADC perhaps, but still). Putting dividers on half the analog pins could work, but would probably be very much confusing.

For now, we thought to just keep the analog pins as-is and leave it to the user to connect the voltage divider if needed...

Regarding the load switch, we thought that perhaps the switch stayed open because current flowed through the 16u2 VCC pins, If so, the diode might not be needed. Later, I realized that the most obvious explanation is that, when USB is unplugged, the VBAT FET switches (partly) on before the switch switches off, and then VBAT, through the switch, keeps the FET from completely switching on? If so, we'd need to keep the diode.

However I was thinking - why not ditch the load switch entirely and just wire VBUS to the charger and VBAT to the regulator? Then you'd just power through the charger always. It seems this is also how you'd wire things with this sparkfun charger module. Or are there any downsides to this? Current limits?

matthijskooijman commented 9 years ago

For the load switch, apparently another simple solution is to add a diode in each power input to isolate them from each other. I think that, because VUSB is always bigger than VBAT (and the difference is more than diode dropout voltage), we only need the diode on the VBAT side, not VUSB. However, I guess we can't afford to have a diode on the VBAT line, since then we get below the regulator's dropout voltage?

This post suggests some "ORing mosfet controllers" to switch between to power sources, but they might be too big or expensive?

Finally, I'm thinking that we might be able to completely remove the load switch and diode? If there is VBUS, the FET will switch off and the circuit is powered from VBAT. If there is no VBUS, the FET switches on and power comes from the battery - everyone happy? I think this is also what @Cisco25 was saying he is using?

matthijskooijman commented 9 years ago

After reading @Cisco25's post again, it seems he removed the switch but not the diode. That makes sense, since without the switch and the diode, VBAT would always turn the MOSFET (partly) off and we'd always have the low voltage condition when USB is not plugged in. Keeping the diode should be enough to prevent this, and we can suffer the voltage drop on VUSB.

amcjen commented 9 years ago

Finally, I'm thinking that we might be able to completely remove the load switch and diode? If there is VBUS, the FET will switch off and the circuit is powered from VBAT. If there is no VBUS, the FET switches on and power comes from the battery - everyone happy? I think this is also what @Cisco25 was saying he is using?

Yep, I think this is correct that we can remove the load switch now. This wouldn't have worked if we were powering the 16U2 via VBUS, because when VBUS was unpowered, the diode reverse current is 100µA, and would have still leaked through the diode into the 16U2, affecting battery life.

Now that we're not powering the 16U2 via VBUS, when VBUS is disconnected, there is nothing on that net (unless something's plugged into the VUSB pin), so there should be no more leakage.

@Cisco25 would you concur?

eeintech commented 9 years ago

Yes I agree, it should work, and I have simulated it to make sure: PowerInput

There is no reverse leakage into D1 (obviously, as not connected to anything when USB is pulled out) and the PFET turns on only when VBAT is connected with no USB. The rest of the time VUSB takes over.

There is some leakage of VUSB into VBAT for a short period of time when VUSB is plugged-in or removed (time for the PFET to turn off), but I don't think this is a big deal.

Note that it is still a better option to keep the PFET as it has a lower Rdson therefore less conduction losses than a diode.

eeintech commented 9 years ago

@erictj Where do you keep the updated schematics? I cannot seem to find them anywhere.

amcjen commented 9 years ago

Thanks @Cisco25! I removed the load switch (and thank you for running it through spice!)

I just pushed the new schematics up to a v1.1 branch here. They're only in eagle files right now, but this will let you have a look.

I'd like to get this board layout completed very soon, at which point we'll make an order for a few new boards to test. Do you mind having a once-over to look for any other issues?

eeintech commented 9 years ago

It looks good overall but two points that would need a second pass is the front-end module and the uC decoupling.

Take a look at the front-end module reference design schematics (page 9) and note the 0.1uF/10pF per each power pin (VCC/VCC1/VCC2):

Note that they also recommend having a small inductor on VCC2, which makes a nice low pass filter out of this pin (this one must be really noisy). Depending on your choice of ferrite bead on the AVCC rail, it could also be used for that purpose, make sure the real impedance gets high in the RF frequency range and place this PI filter as close as possible from VCC2 pin to avoid any noise coming out further than this filter.

As for the decoupling of the two uC, I would recommend to switch to 0.1uF capacitor for each pin and make sure those are place as close as possible from the pin. The 1.0uF "bulk" capacitor can be use in complement to reduce the longest current loop, especially if the power pin is located on the other side on the board compared to the power source.

amcjen commented 9 years ago

Take a look at the front-end module reference design schematics (page 9) and note the 0.1uF/10pF per each power pin (VCC/VCC1/VCC2):

ah yeah, they do have two caps per pin there.

Note that they also recommend having a small inductor on VCC2, which makes a nice low pass filter out of this pin (this one must be really noisy). Depending on your choice of ferrite bead on the AVCC rail, it could also be used for that purpose, make sure the real impedance gets high in the RF frequency range and place this PI filter as close as possible from VCC2 pin to avoid any noise coming out further than this filter.

I think I'll add this one as well. Since we're moving to four layer, we'll have room down there. I want to get this one right.

As for the decoupling of the two uC, I would recommend to switch to 0.1uF capacitor for each pin and make sure those are place as close as possible from the pin. The 1.0uF "bulk" capacitor can be use in complement to reduce the longest current loop, especially if the power pin is located on the other side on the board compared to the power source.

Ok, will add. The Atmel reference design doc talks about adding 1.0µF per VCC pin, but the 100nF certainly can't hurt. There isn't a lot of room, but I'll add them and see what you think

amcjen commented 9 years ago

Hi @Cisco25. Just pushed the changes up to the v1.1 branch. Three comments:

One, I added the additional caps to the FEM. I did not add the caps or inductor to the antenna trace, since that looks like the pi network they use to tune the RF trace to 50Ω. We already have a pi network on our antenna trace.

Two, the FEM's VB_IN pin is an input bias pin. The datasheet recommends feeding 1.8V into this pin, but we don't have a 1.8V regulator on our board. So I tied it to the 1.8V analog VCC (AVDD pin) regulator output from the 256RFR2 to this pin. I'm not sure this is a good idea yet, thoughts?

Lastly, I changed the 256RFR2 decoupling caps to 0.1µF, and added a single 1.0µF cap for the 256RFR2. However, this appnote on page 6 and 7 recommends 1.0µF for all *VCC pins on the 256RFR2 (though recommends 0.1µF for transceiver-only chips like the 233.)

matthijskooijman commented 9 years ago

Regarding the ADC inputs:

17:44 <+blathijs> Also, I think that using differential ADC measurements, we could perhaps get a 3.6V range on the ADC. DIfferential measurement can measure -VREF to +VREF, so if we'd fix one of the ADC pins to 1.8V, we could measure up to 3.6 V (the differential amp would do 3.6V - 1.8V, feeding only 1.8V into the actual ADC) 17:47 <+blathijs> Unfortunately, the ADMUX options don't allow internally select VREF as the negative end on the differential measurement, so it should be applied to ADC1 externally 17:48 <+blathijs> But I think this could be a matter of connecting the AREF and A1 pins on the header and then setting up the AD 17:48 <+blathijs> MUX register appropriately, so this could be made to work without hardware changes (except for wiring up AREF to A1, which can be done by the user with a jumper wire) 17:55 <+blathijs> Not sure if it's ok to use AREF like this, though 17:56 <+blathijs> I was trying to find out what the max load of the internal 1.8V regulators is (e.g. if we can load it externally), but it seems the datasheet doesn't say anything about this at all... 18:02 <+blathijs> eric: Oh, just noticed "IL,AREF", which says "Loading AREF is not recommended", but also says the max load is 0.1mA 18:05 <+blathijs> Nothing about the regulator, though

So, I think with the current design we can effectively double each reference voltage by jumpering AREF to A1 and doing some ADC magic.

For rev1.1 we could consider making this connection internal, and remove the A1 pin (replace it with something else?). However, I'm not convinced if this is a good idea... Any thoughts?

(Note that it can only be A1/ADC1 here, because that's the only pin that can be used as the negative end on a differential ADC reading with 1x gain together with all other pins).

eeintech commented 9 years ago

@erictj

I'm sorry but I just realized that C8 (DVDD) and C19 (AVDD) are bypass caps for the internal regulators outputs (and not input power decoupling caps) so I think they should still be 1.0uF (instead of 0.1uF)... my bad! Other than that it looks good :)

Another question: are C29/C30 (on CRX/CTX lines) recommended by the dual-inverter vendor? What's their reason, stabilize the output? I noticed that you added 100k pull-down resistors on the Front-end amp control lines (and I think that is a good idea) and it should probably be enough. Also make sure R1 (2k resistor on RX/TX line) does not affect the inverter input drive, this value seem a bit high to me.

Connecting VB_IN to AVDD should work fine as it should not source much. During my analog read investigation, I have looked the AVDD power rail and it is very clean.

matthijskooijman commented 9 years ago

On more idea: If the 16u2 stays on always, we could again connect I2C pins together. This could potentially replace the SEROPN and/or VBUS sense line if we'd need an extra pin (though perhaps keeping 1 line as a "something changed, please read status through I2C"-flag from 16u2 to rfr2 is probably useful to prevent needing to poll).

Anyway, I thought of this because I was thinking it would be good to have flow control between the 16u2 and the rfr2. If the rfr2 could set a flag when its buffer was full, or even when it goes to sleep, you would prevent dropping bytes. In the sleep case, it's even easy to pull a scout out of a sleep loop as well, which is currently pretty much impossible.

matthijskooijman commented 9 years ago

Hm, 16u2 doesn't have i2c hardware, so that won't work :-(

dvanduzer commented 8 years ago

@ChuckM Mind taking a look at this one?