Low Voltage Detection & Power Cut IC

[GeorgeOfTheJungle]

The clamping diodes ought to come before the current limiting resistors. IOW move R4 to the right side of D3/D4, R3 to the right side of D1/D2, etc. And I'd put clamps + Rs at both ends of the wires.

[JDW]

The clamping diodes ought to come before the current limiting resistors. IOW move R4 to the right side of D3/D4, R3 to the right side of D1/D2, etc. And I'd put clamps + Rs at both ends of the wires.

Thank you for the advice!

By the way, what do you think of my NPN switching of RB7 (pin 10)?  It's working fine in my breadboard bench testing, passing data both ways.  I've tested it with Vcc=2.9v and it works fine at that low voltage too.  There is a 400mV voltage drop across CE, which is the only minor caveat I'm finding, but again, the two-way data exchange still works fine.  In other words, if Vcc=2.9v, RB7(Tx) would also be 2.9v, but F.SensorRx would be 2.5V.  And at Vcc=3.3v, RB7=3.3v & F.SensorRx=2.9v.  That remains true even if I put RB7 on the Emitter and F.SensorRx on the Collector.  (Removing the 470-ohm resistor doesn't affect the 0.4v drop -- it's definitely the drop across CE.) Again, it's working well.  It's just that I've not found any other schematics or designs online that show someone else out there has done something similar to switch logic signals across CE of an NPN.

[GeorgeOfTheJungle]

I don't understand why do you want or need to switch the sensor's RX line.

[JDW]

I don't understand why do you want or need to switch the sensor's RX line.

For now, let's pretend you (like me) want to cut an Rx or Tx 9600bps data line (reason doesn't matter) and you use NPN as shown in my schematic.  Would that circuit satisfy you; and if not, why not?

By the way, I added a 100k-ohm pull-up to compensate for the 0.4V drop across CE.  That is shown in the revised schematic below.  100k is large enough to ensure the F.Sensor won't be powered by Vdd through that pull-up.  I also moved R3/R4/R5 per your recommendation.

[Ian.M]

Below is the simplified schematic of what I am testing on a breadboard -- "simplified" in that it leaves off my 3V relay, LEDs and other less relevant devices for greater clarity.
<snip attachment>

Fix your designators!!! Half the components have no reference number and there are two instances of  R5 with different values.   

Simplified is not good - Most of the professionals here are experts at reading complex schematics, and it avoids a lot of confusion if you show us the schematic you have actually built, (or that you *believe* you have built).

I don't have any MOSFETS in my parts stock, so I breadboard-tested with a PNP.  The PNP works great to kill power to the F.Sensor when Vdd dips below 2.81v, but the PNP's base resistor results allows a continuous 4.2mA current flow as long as the Base is LOW (fed by the Comparator1 OUT), which is most of the time.  If using a P-MOSFET will eliminate that 4.2mA then I should use a FET instead.

You do need to get some MOSFETs, but we understand that organising a parts order and wating for it takes time and its useful to be able to push on with a substitute.  However IMHO you haven't got enough base drive for the 2SD772.  The rule of thumb for a single BJT saturated switch, is use a 'forced Beta' of 10, i.e. Ic_max/Ib should equal 10.  Therefore for a peak load current of 75mA, you should be providing a minimum of 7.5mA base current.  Replacing the 620R resistor with a 220R one will improve matters, at the expense of power consumption, which is irrelevant when breadboarding with a mains PSU.

Using an NPN to break Tx in the manner shown in the schematic actually works, and signal integrity looks fine on the scope, but I am unsure if that's a sound approach -- it is a bit different than what forrestc recommended in (1) of his earlier post.

If you get the right transistor, designed for reversible switching applications, with a high reverse h_FE, its viable, but its still going to compromise the logic levels at the sensor and the signal's falling edge.  Can you afford to throw away noise margin?

My switching power supply has internal protection against the output (3.3v@250mA) being shorted to ground, so I think the PNP's collector (which powers the F.Sensor) should be OK as shown on the schematic.  Leaving Ground as a straight-through connection between boards is probably okay as well for the same reason.  And the 3 signal wires have basic diode ESD protection with resistor as shown (for the PIC side circuit board).

The time to design in and test over-current protection for the sensor supply is *now* while you are still breadboarding.  Relying on your 3.3V switching PSU to limit the current is foolish, as 250mA is plenty to destroy ICs if it gets shorted to an output pin, and the internal bulk decoupling capacitor at the PSU output can probably transiently supply several amps or even tens of amp, if shorted.

Also 1N4007 diodes aren't very good for ESD protection - too slow, too high Vf, and too much junction capacitance loading your signals.  To be fully effective at eliminating CMOS latchup, external ESD protection diodes must clamp at a low enough voltage for the internal parasitic silicon diodes in the CMOS ICnot to conduct significantly.  That means your clamping diodes need a Vf below 0.7V while carrying a significant current pulse, so Schottkys are frequently preferred.  BAT54S is a good SMD choice here, with two series diodes in a single three pin package, or axial glass wire-ended BAT81, BAT82 or other similar small signal, low to medium voltage Schottky for breadboarding.

George is half right^* - the purpose of the resistor between the clamping diodes ant the IC pin is to limit the current into the pin when, at the peak of the ESD strike surge, the clamping voltage goes more than 0.6V outside the rails, but you still need another resistor in series with the signal, the other side of the clamping diodes, between the clamp and the external connection at risk of ESD, to keep the peak ESD strike current down to what the clamping diodes can actually handle (transiently). 

* Maybe a bit more than half right: if you only have space for  one resistor and the Vcc supply is current limited, the CMOS chip may well be able to survive latchup and return to normal after power cycling, but if you don't limit the peak ESD discharge current and the ESD protection diode shorts out, its game over!

I've not had time to do the CLC or the PIC internal voltage division (to eliminate R1 & R2) that forrestc suggested, but I intend to do that soon and will report back at that time.

We'll be waiting for an update.

We are also still waiting for the bench and breadboard photos so we can see if there are any more obvious howlers like the test lead EMI pickup issue, that we could warn you about before you waste more days!

[JDW]

Compare Figure 2 at the DMG2310L datasheet at https://www.diodes.com/assets/Datasheets/DMG2301L.pdf .  Note at 3V you can actually push 10A through it.   The Vgs(th) of this part is down around 1V, and you'll note that the Id at this level is also close to zero.

Another chart of interest in the DMG datasheet is Figure 4.  This is Vgs voltage vs on-resistance.   You'll notice that the resistance doesn't really start dropping until somewhere just below 2V.  At 3V, it's pretty close to as good as it can get, and any additional voltage isn't really all that helpful.   So this Fet is really useful only above 2V with 3V or over being ideal.

I'm not sure what you mean about "Figure 4" in that PDF, as Rds(on) decreases with increase in Vgs, starting at about 2.0V and going up to 8V.  "As good as it gets" would appear to be 8V, where Rds(on) looks to be about 70m-ohm.

If Rds(on) is 150m-ohm for the voltage my PIC would need to use, the voltage drop across Source & Drain would be 15mV, which I suppose is acceptable. 

[JDW]

Fix your designators!!! Half the components have no reference number and there are two instances of  R5 with different values.   

I simplified the schematic, and for that reason alone I only put designators on the parts I felt we would discuss.  (But I fully understand your desire to have the full schematic.)  And as to there being two R5's though, that was a mistake in my first upload which I corrected an hour later.  So a page reload will reveal (or should reveal) the newest schematic in that post of mine.  I then revised the schematic for George.  And later in this post will be yet a third revision.

Simplified is not good - Most of the professionals here are experts at reading complex schematics, and it avoids a lot of confusion if you show us the schematic you have actually built, (or that you *believe* you have built).

Understood.  But with all the time I've spent on replying here, I've not had the time to flesh out the full schematic.  I won't have that until Monday at the earliest.  For now, I've made some revisions as per your advice.  I can probably get away with using the 2SC3326 with high reverse Hfe. There are now 470-ohm resistors on either side of the diodes, and I changed 1N4007 to BAT54S. I also added the power supply portion.



I've noted your suggestion about the PNP's base resistor being 220R, but I based my 620-ohm resistor size on Hfe-min= 30, as per the datasheet. True, that spec is for Ic=-20mA, but isn't an Hfe=10 an "assumption" as well?

I am actually passing 100mA to the F.Sensor when it is fully powered and its LED is turned on.  My 75mA figure was measured with my uCurrent Gold and Fluke 116, but I see 100mA when using my Fluke 8845A, which I trust more.  So it's 100mA, and the 620-ohm base resistor of that 2SB772 is passing the current just fine.

Thank you again for your excellent help to date, Ian.  I certainly appreciate your insights and sharp eye for detail.

[forrestc]

I'm not sure what you mean about "Figure 4" in that PDF, as Rds(on) decreases with increase in Vgs, starting at about 2.0V and going up to 8V.  "As good as it gets" would appear to be 8V, where Rds(on) looks to be about 70m-ohm.

If Rds(on) is 150m-ohm for the voltage my PIC would need to use, the voltage drop across Source & Drain would be 15mV, which I suppose is acceptable.

The point I was trying to make is that at at around 3V, you start having to add a lot more voltage to get any meaningful change in rds(on).  Between 2 and 3V, the Rds(on) drops by around 80mohm, between 3 and 4, you only drop a fraction of that.   In fact, going all the way from 3 to 8, you only gain around another 30mV.

[forrestc]

I don't understand why do you want or need to switch the sensor's RX line.

The TX to sensor Rx line idles high and has at least 20mA of drive, probably more.

When you turn the power off to the sensor, the TX line will try to power the sensor through the sensor's input protection diode.   My suggested solution of automatically turning off the TX line I think would probably be cleaner.

[Ian.M]

An incomplete diagram isn't an issue -  just draw a functional block for anything you haven't finalised, but label the signals going to it meaningfully.

Sure, a forced h_FE of 10, is a rule of thumb assumption, but its specced in many transistor datasheets for the Vbe_sat and Vce_sat  graphs.  Therefore it makes sense to do so to ensure deep saturation unless your specific transistor datasheet says otherwise. It may only make one or two hundred mV difference to the Vce_sat drop  For a peak 100mA load I'd probably go for 180R, but check the actual voltage drop across it as the output current is getting high enough for the Voh droop to become significant, especially at only 3.3V Vdd.  If the PIC cant source enough current you may need to add a small signal PNP emitter follower between the pin and the high side PNP Vcc switch's base resistor.  You will then need a pullup of 10x the base resistor at tje emitter follower end of it to get a clean turnoff, so its best avoided unless your MCU has really wimpy I/O pin drivers.  Nearly all this mess of resistors and BJT driver transistors goes away when you get a suitable MOSFET.

A no active devices bodge for the TX line to tide you over till you get CLC or interrupt driven gating for it working, would be a 33K series resistor with 100pF in parallel with it to speed up the edges, and 3K3 between sensor Vcc and ground.   Worst case, the 33K resistor limits the current when the sensor is off to under 0.1mA, and it forms a potential divider with the 3K3 resistor, limiting the 'phantom' Vcc voltage to under 0.25V.  The 3K3 resistor wastes 1mA, but that's acceptable for bench testing and initial trials.

More details of the sensor 'bezel touch' signal would be useful.  In fact why not go the whole hog and give us a link to the sensor datasheet?

[GeorgeOfTheJungle]

However one probably should isolate the sensor's serial RX pin, as that line probably idles at logic '1', and allowing the input protection to clamp it could result in out of spec voltages on the sensor Vcc rail and a return of the memory corruption problem

I still don't see the need to cut/isolate RX when the sensor is powered down and the PIC isn't. 470R times two (or times 4 if you put two Rs at each end) would give at most ~ 3.3/1k or /2k = 3.3 mA or 1.6mA which isn't enough to do any harm in any way as far as I can see. Not to mention the huge voltage drop means it can't possibly power up/turn on the sensor board.

[Ian.M]

Without seeing the sensor datasheet we cant know if 1.6mA is potentially harmful.  Way back in the first post JDW wrote: "The Sensor draws about 75mA in its full power state (and microamps when sleeping) ...", so if it starts up in sleep mode, its Vcc could potentially reach nearly 3.3V just from parasitic power through several K of resistance from an idling UART TX pin, provided there are no other loads on the switched Vcc rail.  Obviously, its not going to stay in sleep mode after powerup for long, but if Vcc rises into the danger zone before it exits sleep, and the firmware doesn't lock out EPROM writes for an adequate interval after powerup, memory corruption is highly likely.

[GeorgeOfTheJungle]

But VIn will drop to ~ nought as soon as it tries to exit sleep mode. On top of that, he could put RB7 to 0 programatically when needed just to be sure.

Without seeing the sensor datasheet we cant know if 1.6mA is potentially harmful.

1.6e-3A * 2000Ω = 3.2V of voltage drop across R. I don't think the sensor board can run much less erase the flash with 0.1V at VIn.

[Ian.M]

If there's 1.6mA available with the far end grounded, there's about 160uA available with the far end Vcc at 90% Voh - 1 * diode_Vbe_drop.   That's right in the middle of the OEM's 2.0V to 2.5V memory corruption danger zone. If the load's a lot lower Vcc will reach just above the top of the danger zone so any protection in the sensor firmware may deactivate.  How many us or ms can the sensor's onboard decoupling caps hold up Vcc above its Vbor or MCU's minimum operating voltage? 

And then we have situations like Microchip's 8 bit PICs' tendency to keep executing instructions and incrementing the program counter slightly below the minimum voltage, but some instructions glitch.   That gave a high probability of hitting the FLASH  or EEPROM write routine if present, and resulting memory corruption, so that slowly rising/falling Vdd without BOR enabled had a high probability of bricking anything that used a bootloader or EEPROM.

There's got to be something hinky about the firmware or hardware design in the first place for it to be vulnerable to memory corruption on brownout, as most modern MCUs have an internal BOR or UVLO module that if enabled, will hold them in reset below their minimum rated voltage, and together with an appropriate delay after powerup before unlocking writes, can reduce the risk of corruption by many orders of magnitude, and virtually eliminate it if there is sufficient bulk capacitance + self-monitoring of its Vcc, to confirm there's enough energy available to complete the pending write sequence tto leave the memory structures consistent.    However they probably couldn't meet the sleep current specs marketing wanted with BOR/UVLO enabled, and writing robust NV memory access code that handles  write errors and recovery from them properly isn't a job for the intern or the CEO's grandson, so it isn't so much 'cant fix' with a firmware update but 'won't fix'!   

I've already stated the easiest fix - increase the TX line series resistance and put a load resistor on Vcc sufficient to keep it well below the danger zone. 

If quiescent current is a major issue, I've already recommended the 74LVC1T45, which is explicitly specified to be hi-Z when only one side of it is powered, or as has already been suggested, simply make the master firmware disable the TX pin output or override it and drive it low when the sensor Vcc is meant to be off.  No CLC is needed - simply disable the UART and release the pin (and set low/hi-Z) in the comparator ISR on sensor Vcc falling below the threshold, + flag to the main code that the UART is not available, so it aborts any pending data transfer and knows to reinitialise it when the sensor is next powered up.

[forrestc]

If quiescent current is a major issue, I've already recommended the 74LVC1T45, which is explicitly specified to be hi-Z when only one side of it is powered, or as has already been suggested, simply make the master firmware disable the TX pin output or override it and drive it low when the sensor Vcc is meant to be off.  No CLC is needed - simply disable the UART and release the pin (and set low/hi-Z) in the comparator ISR on sensor Vcc falling below the threshold, + flag to the main code that the UART is not available, so it aborts any pending data transfer and knows to reinitialise it when the sensor is next powered up.

The only reason I suggested the CLC was that there was some discussion that the worst case delay of ~2.5ms due to interrupts being off during HEF writes was too slow, and that disabling the UART in the ISR wouldn't be fast enough.   The whole purpose of the CLC was simply to shorten that worst-case delay to <1uS.

Just to be clear, I don't disagree with your assessment at all.   Just wanted to clarify the reason I was suggesting the CLC in the dataline.

I really suspect what is going on with the fingerprint sensor is that they're watching for multiple crossings of some voltage around 2.25V within a short period of time.   If they see more than a given amount, they wipe internal flash to prevent any possible power glitching attack.   In that case, if one hangs around with Vcc in 2.0 to 2.5V then there is a good chance that the memory will be wiped just due to Vcc noise. 

[Ian.M]

Hmm. I'd respond to power glitching by wiping a series of flag locations and for each one wiped, doubling the delay after Vcc becomes stable within  its valid range before responding to any commands or fingerprints.  It only takes an initial 10 second lockout and by the 16th glitch attempt they'll have to wait a week before they can try again.  Reset the flag locations on command only if power is stable and the master fingerprint is used for authentication.

[JDW]

Without seeing the sensor datasheet we cant know if 1.6mA is potentially harmful.

Here is the datasheet.

Here is the Programming Guide.

Here is a marked-up photo I took of the bottom PCB of the sensor (the top is just the sensor itself with some ceramic caps and connectors at either end). 

As mentioned in my previous post, my earlier mention of 75mA current consumption was in error.  For some reason my uCurrent Gold was giving me that value on my Fluke 116 DMM, but when I later tested with my benchtop Fluke 8845A, I measured a solid 100mA flowing to the sensor at 3.3V when the sensor was powered on and its LED lit.  So let's please forget the 75mA number and use the correct 100mA value going forward.  Also note that the datasheet mentions 130mA, which I assume are peak current because I could not measure anything above 105mA during a lot of testing with my Fluke 8845A.

The manufacturer finally answered my question to them about the two 5-pin components marked "A2RC" in my photo by saying they are both LDO's used in a proprietary way they cannot disclose, which assume means they are somehow involved in the flash memory anti-tampering auto-wipe security feature.  (That means there are a total of 3 LDOs on this fingerprint sensor -- U3, U4 & U5.) When I cited some Vin voltage-range specs from the Holtek "02A-4" MCU datasheet, the manufacturer replied that MCU was customized by Holtek for them, but they would not disclose how.  They emphasized that the Holtek 02A-4 MCU needs 3.3V and that I should not operate it within the 2.0v to 2.7v danger zone, nor should it ever be fed 5.0V.  This is an important detail since the UART side Vin connector can accept voltages up to 6.0V. 

Using continuity-check while probing the bottom of the fingerprint sensor PCB, I found that the 5V pad on the "UART side" shown in the photo leads straight to the Holtek 5301 3.0V regulator on the TOUCH IC side, which in turn powers the ARM processor and the Winbond Flash IC.  However, Vin for the Holtek 02A-4 MCU comes straight in (unprotected, but with some ceramic decoupling capacitors) from the connector atop the TOUCH IC side.  And again, according to the manufacturer, Vin for that 02A-4 MCU must be 3.3v.  They refused to disclose a range of input voltages for it, but I tested that it works fine at Vin will down into the 2.0v to 2.7v danger zone.

The connector on the TOUCH IC side can be left alone and unpowered (i.e., when not connected, the Holtek 02A-4 MCU would be completely powered off).  But when the 02A-5 MCU is powered (it draws less than 60uA even when powered) the connector on the TOUCH IC side provides an output from a leg on that Holtek 02A-4 MCU which becomes HI for as long as a finger is touching the metal frame that surrounds the optical fingerprint sensor.  When you remove your finger, that output goes LO.  You can of course issue UART commands to the sensor to ask it if a finger is pressed, but they provide this other way to get that info which is faster and provides that info even when the fingerprint sensor is in sleep mode. 

Ground for the Holtek 02A-4 MCU is straight through to the UART side connector, so to use the TOUCH IC connector means one only needs to connect Vin (which must be 3.3v) and then one can use the Finger Detect Output, which again comes straight off the I/O pin o the 02A-5 MCU.  The manufacturer confirmed that so long as the UART side connector's Vin is a nominal 3.3V, I can safely connect the TOUCH IC side's Vin to the UART side Vin, powering them both at the same time.  And since the TOUCH IC side draws so little current, it's fine to keep it powered all the time.  And that is why you see it connected in such a way on my simplified schematic.

Ground for the Holtek 02A-4 MCU is straight through to the UART side connector, so to use the TOUCH IC connector means one only needs to connect Vin (which must be 3.3v) and then one can use the Finger Detect Output, which again comes straight off the I/O pin o the 02A-5 MCU.  The manufacturer confirmed that so long as the UART side connector's Vin is a nominal 3.3V, I can safely connect the TOUCH IC side's Vin to the UART side Vin, powering them both at the same time.  And since the TOUCH IC side draws so little current, it's fine to keep it powered all the time.  And that is why you see it connected in such a way on my simplified schematic.

By the way, if you watched the unlisted videos I posted on YouTube, you will spot the benchtop power supply I used during testing.  That power supply normally triggers the auto-memory wipe of the fingerprint sensor nearly every time I switch it off and then on again.  But after I added the low voltage detection and power cut via PNP & NPN you saw in my schematic, the auto-wipe doesn't occur anymore -- not even when I deliberately glitch-test on my breadboard.  I've tested this power supply via OFF/ON almost 100 times, so I can say that with a certainty.  I don't see any glitching when I probe the output of that power supply while connected to my breadboard.  The only thing I see is that it someone slowly ramps up voltage from 0v to 3.3v, which is no doubt an intentional soft start inside that power supply.  So perhaps the fingerprint sensor manufacturer has setup their circuit and software to look for a certain voltage ramp?  They made it clear I should not power it with 2.0v to 2.7V, but they didn't specify how long it could be in that voltage range before the auto-wipe occurs. 

I have also been testing at my computer using this USB-to-3.3V interface and I almost never experienced auto-wipe no matter how many times I yanked out and inserted the USB connector.  Regardless, the PNP & NPN circuit shown in my most recent schematic has, in my testing thus far, eliminated the auto-wipe problem.

[RIKRIK]

What a bus driver or tristate buffer?. However you would need a opamp as a voltage comparator to turn it on and off.

[JDW]

You're concerned about power from the PIC TX line being fed into an off sensor, and it powering up the device, not the other way around.

The software interrupt would probably work really well, well except when it is too slow.   Other options:

3) Use a tri-state buffer gate.   These are available around ten cents US in reasonable quantities.   After some digging, I found the SN74LVC1G240 which has a active-low output enable which matches the polarity of the output of the comparator when driving a P-Channel FET.   There are also active-high output enables.     You'd power these from the same VCC as the PIC, and then tie the OE pin to either the output of the comparator, or the switched HV rail depending on the OE polarity.    This would effectively turn off the TX pin when the power goes off.    Note that the SN74LVC1G240 I mentioned has an inverting gate, so you'd need to invert the TX pin on the PIC like the above solution.   Some of the others don't invert, but the ones I found don't have an active-low OE pin, and I think I'd want to tie this to the output of the comparator so that this pin shuts off as quickly as possible instead of starting after the PCH fet turns off.

I found the following two 3-state unidirectional non-inverting buffers with active-low enable and internal ESD protection:

NC7SZ125P5X - ESD Human Body Model Protection: 4000V max, Operating Temp: +85°C max

NL17SH125P5T5G - ESD Human Body Model Protection: >3000V max, Operating Temp: +125°C max

Do you know if the ESD protection is on the input, the output or both?  (Datasheets don't specify this.)  If ESD protection is on the Output, then would the buffer alone be sufficient as shown in the modified (& simplified) schematic below?  (Note the buffer on RB7 with no supplementary ESD protection.)



Note in the bottom left that I also swapped out my PNP for the P-MOSFET you suggested.  Not sure if R10 being 100k is too big, but turn on time isn't critical.  It will be ON most of the time, so 100k would help keep wasted current consumption to a minimum.

[JDW]

One other thing:    Step 12 on the DAC is pretty close to the threshold you were looking at for the comparator input.  2.73/32*12 =1.023V.  So, if you use the DAC as the divider instead of the external resistors, you can eliminate those as well.     If you run the FVR at 2.048V instead, you can then use step 24.  2.73/32*24 = 2.047.   Step 25 would end up being 2.62, and Step 22 would end up being 2.979 as a threshold.     You can pull the DAC reference from either Vcc or from the external Vref pin, which could be used as a remote sense if you have a spare cable pin to hook Vref up to the far end's Vcc (assuming you're not otherwise using Vref).   I haven't done tolerances, etc. on these so they might need to be adjusted.

I spent the day testing the DAC, since I had never used it before.  The 16F1508 datasheet has a number of errors, and the DAC pages are especially afflicted.  The datasheet specifies "DAC1CON0" & "DAC1CON1" but using those generates Assember errors.  "DACCON0" & "DACCON0" are correct.  Then on page 143 in section 16.3, paragraph-2 ends like this:

"Reading the DACxOUTn pin when it has been
configured for DAC reference voltage output will"

"Will" what?  Nobody knows!

Despite this hassle, I finally got the DAC working with Comparator1.  Keeping the threshold somewhat close to 2.70v is desirable because I don't want it to go too high with Hysteresis enabled.  So I thought Step-12 in combination with FVR=1.024v would be best.  On my breadboard test I measured the lower threshold to be 2.725v (that voltage and below results in Comparator1-OUT=HI, which then cuts power to the fingerprint sensor).  "Tolerances" are the key issue though.  I wouldn't want the power-cut to start at below 2.70v.  Table 29-16 on pg.332 in the 16F1508 datasheet says the parameters are characterized but not tested, and Note 1 links to graphs that have nothing to do with the DAC.  However, it does say the absolute accuracy is 1/2 LSb, which must be referring to bits 4:0 of DACCON1.  So +/-0.5LSb would be 11.5 or 12.5 (since I'm using 12).  That yields the following calculations:

EQUATION 16-1:
DACx_output = ((Vsource+  –  Vsource-) x DACR[4:0]/32) + Vsource-

Since Vsource- is Vss(GND) according to Figure 16-1 in the datasheet, and since Vsource+ is set to Vdd in my code, we have:

DACx_output = Vdd x DACR[4:0]/32

Find Vdd when DACx_out = FVR(1.024v):

1.024v = Vdd x 12/32
Vdd = (1.024v x 32) / 12 = 2.731v (nominal)

And with the 1/2LSb tolerance, we have:

Vdd = (1.024v x 32) / 12.5 = 2.621v (min) <- too low!
Vdd = (1.024v x 32) / 11.5 = 2.849v (max)

So a power cut-off threshold of 2.621v would be a problem, seeing it is below the 2.70v specified by the fingerprint manufacturer.

Using Step-11 instead of 12 would give:

Vdd = (1.024v x 32) / 11 = 2.979v (nominal)
Vdd = (1.024v x 32) / 11.5 = 2.849v (min)
Vdd = (1.024v x 32) / 10.5 = 3.121v (max) <- too high!

Using a 2x multiplier on the FVR and Step-24 would yield:

Vdd = (2.048v x 32) / 24 = 2.731v (nominal)
Vdd = (2.048v x 32) / 24.5 = 2.674 (min) <- too low!
Vdd = (2.048v x 32) / 23.5 = 2.789v (max)

Using Step-23:

Vdd = (2.048v x 32) / 23 = 2.849v (nominal)
Vdd = (2.048v x 32) / 23.5 = 2.789 (min)
Vdd = (2.048v x 32) / 22.5 = 2.913v (max) <- a bit high, but perhaps acceptable.

So I bench-tested FVR with a 2x multiplier and Step-23 on my DAC and measured the following:

Lower Threshold Voltage: 2.874v (this and below cut power to F.Sensor)
Upper Threshold Voltage: 2.900v (this and higher restore power to F.Sensor)

And that small 26mV difference between Upper and Lower is with Comparator Hysteresis ON. I must assume it has something to do with using the DAC instead of external voltage divider resistors.  With the resistors I was getting a 66mV difference between Upper and Lower, which offers better noise immunity.

If you have any thoughts on this and my previous post, please let me know.