Possible firmware problem leading to bricked fingerprint reader on T530

Question

I tried to send this through support channels but they told me there was no way to reach any developers through phone support.  One guy said the developers do read the forums so I am posting this here.
Basically this is what happened: (twice!) 
I had pre-boot fingerprint authentication and also swipe to power on enabled on my T530. 
Everything worked great until I wanted to be sure I discharged the battery all the way by letting the machine power off from a low battery. The way I did this on previous laptops was to just run memtest86 or something until the battery ran out. but since I use the laptop in UEFI only mode memtest86 doesn't work. so I used the built in lenovo memory diagnostics.  after the laptop powered off. I turned it on again. and it quickly powered back off. Afterwards the fingerprint reader refused to work for anything other than power on and refused to be connected to by the Lenovo fingerprint software. 
I originally thought this was because I had turned it back on and the system was talking to the fingerprint reader as part of start up and didn't complete since the power went right back off again..
that is until I managed to break my replacement fingerprint reader. This time I just ran the memory diagnostics as before until it turned itself off. (and didn't try to turn it back on right afterwards) This time it also bricked the fingerprint reader in such a way that caused it to keep connecting and disconnecting from the USB bus somehow. 
My theory is that either the UEFI firmware or the embedded system controller is not finishing the conversation with the UPEK touchchip that puts it into the low power swipe to power on mode when the battery is critically low and is causing the device firmware to become confused (the fingerpritn reader is not just a dumb reader, instead it's basically a small embedded computer). It's very easy to re-produce this problem. and I wish I had a way to just submit a bug report to someone instead of posting to a forum.
I now have a working fingerprint reader and I've disabled swipe to power on, hoping that this wont come up again. (I'm also going to avoid doing the memory test until power off thing too obviously...) Still I think it would be a simple fix to make sure it doesn't attempt to talk to the fingerprint reader as part of shutdown if the battery is low. 
I still have the other 2 fingerprint readers if anyone at Lenovo wants to take a look at the state this leaves them in (although it should be very easy to re-produce this in house) 
aside from this I'm very happy with my Thinkpad and I plan on getting an extended warranty and to also make my next laptop a thinkpad as well (assuming they don't do someting stupid like get rid of the trackpoint/trackpoint mouse buttons or decide to start making the thinkpad small and flimsy)

Answer 1

Yes I tried that. I also even did research into the upek (now owned by authentec) chip and found a dagnostics utility that also pretty much confirmed that the chip was failing to communicate. (and gave the same information that the lenovo fingerprint reader gave me) The. First one I killed could be seen but was stuck in the swipe to power on mode and wanted to be authenticated to somehow (error is could not authenticate pasport) before it would do anything else. And both the firmware and the fingerprint software had no luck doing so.
The second one I killed behaved differently, It shows up on the usb bus for a few seconds and then dissconnects and then does it all over again forever. In both cases I believe the firmware inside the fingerprint reader is being confused in a a way that is persistent across power cycles. Replacing the reader restores normal operation again. i didnt bother with thee diagnostics tool the second time incase you think I killed them with that. This time around it had problems booting and had to lift up the keyboard and unplug the cable from the palmrest, reboot and disable the fingerprint reader port before plugging the cable back in to restore normal operation to my system. otherwise it would boot only part of the time. (you could also disable pre-boot fingerprint support and it would also boot fine but then you would see a steady log of it attaching and detacthing in both windows and linux, which ofcourse is annoying) 
I have saved those two parts and will ship them to you if you want to look at them.
I seem to have a knack of running into strange corner cases like this since I always seem to use my computers/software just different enough from the averge person to run into things the developers didn't consider.
I have no idea if this thing can happen any other way than the system powering off inside the memory test utility. but I would bet it is possible in other cases and might as well be looked into.
I would bet when you try to re-produce it that it can only be re-produced with the swipe to power on feature enabled. am also pretty sure that what my guess is is likely correct, that when the system forces itself off with a low battery either the UEFI firmware, or some embedded controller talks to the chip to enable the swipe to power on feature and it's powering off before the fingerprint reader is ready when the battery is critically low, screwing up the state of the firmware on the fingerprint reader chip.  when I was doing searching around I was really hoping there was some vendor tool that could reset the chip, but no such luck at least nothing that's public. UPEK was bought out by authentec and a lot of their site no longer exists, authentec also seems to be bought out by digital persona and shut down much of the authentec site as well, and seem to be only licensing the IP of authentec to certain people.