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).

  • 3
    Sounds like an XY problem, if I've every heard one. Back up a bit, and tell us the problem you're trying to solve. – Scott Seidman Dec 6 at 14:40
  • 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. – fest Dec 6 at 14:42
  • 2
    Are you trying to fix this mistake without modifying either the board or the firmware? Is that what you really want to do? If so, please edit your question to add those details. – Elliot Alderson Dec 6 at 14:51
  • 1
    If I were debugging, I'd start with the PREVIOUS hardware revision, and cut your inputs one by one until the current behavior is duplicated. If this were important, I'd also review procedures to figure out how this happened, and do something to make sure it can't happen again. – Scott Seidman Dec 6 at 16:11
  • 1
    "Auditing the full software ...." To me that seems to be the crux. What I read is that you have a lot of SW but don't know what is in it. Somewhere there must be code which sets up your I/O ports. Normally those have specific names. A simple 'grep' should show you all the places where the pin is configured. – Oldfart Dec 6 at 16:13

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.

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.

New contributor
G. Gross is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.