Given: a microcontroller in QFP package. A pin is configured as digital input, no pullups/pulldowns. The physical pin is not connected to anything else, besides the pad on PCB.
Is there a way to force the state of the digital input (high/low) without physically touching the pin? Electrostatic field? Heating the IC to increase leakage current in clamping diodes?
To those wondering why: suppose you are working on a complex system. In the previous HW revision, there was a button + pullup/pulldown resistor. The button and resistor was removed in the next hardware revision. The firmware team did not remove the code which was processing the input, just initialized the system to desired state. Since the software still reacted on long button press (not just rising/falling edge) and did not have sufficient logging, this led to very hard to debug issues down the road (requiring multiple man-weeks of debugging to find the root cause).
What I'm looking for is a relatively quick test to see if there is no software reaction to "supposedly unused" input pins changing state. Auditing the full software running on the MCU is non-trivial task (>1M LOC).
This is a tough problem - If you can't physically touch the pin your options are pretty limited. And it sounds like you can't modify the software either. I don't know what your debugging capabilities are, but can you run the SW/FW in some kind of debug mode and set up a flag or break point if the pin changes states?
if you want to heat/cool, you'd probably have to go outside the MCUs specifications to see anything happen, since it's designed to have the inputs working normally under its full specified temperature range. That could be damaging to other parts perhaps or the MCU itself. Even then it seems unlikely and unreliable.
It seems unlikely that the QFN pin itself has enough iron/nickel/etc inside to be of any use with a magnetic field. Perhaps as you surmised, some kind of electrostatic field might have an impact, but you'd probably need a really big one, and you'd risk zapping the board with an ESD hit.
If you cannot audit the software, then you should modify one copy of the hardware to conduct tests by connecting that pin to an external driver. You can do this with fine wire under a soldering microscope, especially if it is only one pin and not several adjacent ones. With care you can even solder to the side metallization of a QFN, but your QFP will be substantially easier.
You could also manually hold an injector probe in position during a shorter duration test.
And you could make a custom hardware revision granting easier access.
But this is really going about things the wrong way. Given source code it should be fairly easy to automatically identify points where I/O is accessed and then manually review those sections of code. If the code uses library functions for I/O you could potentially even write filtered versions that forced the reported state of inputs "unused" in a hardware revision. If it doesn't use libraries it should at least be using structures or definitions for the registers.
If you have only the binaries for your program, or you have code that is full of hard-coded hardware register addresses, you have organizational problems beyond simple solution.