Electronics > Projects, Designs, and Technical Stuff
Low Voltage Detection & Power Cut IC
<< < (13/14) > >>
GeorgeOfTheJungle:

--- Quote --- 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
--- End quote ---

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.


--- Quote from: Ian.M on September 06, 2019, 10:15:48 am ---Without seeing the sensor datasheet we cant know if 1.6mA is potentially harmful.

--- End quote ---

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:

--- Quote from: Ian.M on September 06, 2019, 11:56:58 am ---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.

--- End quote ---

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. 
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod