Assigning unused port pins as outputs?

[Circlotron]

I've been using a certain micro in one particular board and because of chip shortages I substituted another from the same family that I am now using in a different board with identical function but different pinout so I had to change all the DDRs. Otherwise the firmware is identical. Previously I had all unused pins set as outputs but this time I just left them as neither, which I presume would make them default to their special function. This micro for example has inputs for capacitive touch sensing. Anyway, I just spent the last two days stuffing around trying to get it to work. It would mostly but not completely. And sometimes it would change its mind. Other times it would run for a while then stop. Typical behavior of floating inputs. So... is setting unused port pins as outputs always a definite must, or are only some chips vulnerable to this type of behaviour? NXP MC9S08PT series.

[AndyC_772]

Always, always, always read the data sheet for the specific device you're using. Never just assume.

It's very common for a microcontroller which has high impedance, (usually) analogue input capability on a given pin, to have it default to that mode at power-up. This is completely correct and necessary if the pin is connected to circuitry that would react badly to being driven with a digital output, and safe otherwise. You can always add a pull-up or down resistor to your design if need be.

Unused pins should be set as outputs, or as inputs with a pulling resistor. The latter may be a better option if you anticipate adding additional inputs to a design in future.

A floating input may be harmless, but it will often cause excess current to be drawn by the CPU (think how a CMOS gate works, and what happens if the input is part way between fully high and fully low). Also bear in mind that the moment you probe a floating input with a scope probe, it'll immediately be pulled low, so you'll never see the voltage level it was really at (or whether it was, in fact, even oscillating).

[Siwastaja]

It's unlikely your random and unspecified problems are due to floating inputs, in my experience I have never seen any other issues than slightly increased current draw. If the thing fails, look elsewhere first. I'm not saying it couldn't be the problem, just that it's one of the most unlikely culprits.

That being said, of course it's a good idea to ensure either GND or Vcc level on the pin by external hard connection, external pull-up/down, internal pull-up/down, or internal "hard" connection by setting the pin as output driving either '1' or '0'. It's worth noting the latter options work only after the MCU have already booted and started running your init code.

Often, on some pins, you can also turn the digital input circuitry off, for example in AVR by using the Power Reduction Register's Digital Input Disable thing if I recall correctly, on STM32 by setting the mode register to ANALOG. Then any floating voltage does not cause increased current consumption.

Grounded pins (internally or externally) gives a very slight (mostly theoretical) EMC/EMI improvement as well.

[Circlotron]

It's unlikely your random and unspecified problems are due to floating inputs,

Maybe it varies from one chip family to another. All I know is that when I made those unused pins outputs it finally snapped into action. The actual function that wasn't working was retrieving a 2-byte value from a lookup table using indexed addressing. I think it was simply returning a zero. While leaving no stone unturned I also found a bug in another chip's firmware that talks to it, so that was good too. 

[Siwastaja]

Sounds like a case where you might want to invest some time into finding out why it got fixed. I would start by setting half of the pins as outputs at a time for a "binary search" to find if any single pin is the culprit.

Yeah yeah, I know the great feeling "now it works, don't touch it anymore" but in the long run, it's also ugly to see bugs resurface. For example, I have had cases with variable alignment errors making it look that certain specific changes fix or break things but the functional changes apparently "fixing" the problem hadn't anything to do with the problem, except move things to different places in memory.

[Circlotron]

I would start by setting half of the pins as outputs at a time for a "binary search" to find if any single pin is the culprit.

Excellent idea. Thank you!

[mikeselectricstuff]

Previously I had all unused pins set as outputs but this time I just left them as neither, which I presume would make them default to their special function

Why would you assume that ?  What do you mean by "neither" - pins generally default to inputs if not initialised.
Different micros handle things differently, but special functions tend to need to be explicitly enabled ( either via the pin selection or enabling the peripheral), the pin defaulting to I/O  otherwise.
Although floating input pins generally only cause unpredictable increased current draw, there could be other effects, e.g. if that pin can cause an interrupt - that would give you a really bad day.
Unused  I/O pins should generally be set to output unless there is good reason to do otherwise ( e.g. they're externally tied to 0V or Vdd for PCB layout reasons)

[SiliconWizard]

So... is setting unused port pins as outputs always a definite must, or are only some chips vulnerable to this type of behaviour? NXP MC9S08PT series.

It... depends. Of course. Sorry I do not know the series you mention, so I can't comment for this particular one.

But it all depends on how IOs are implemented on a particular MCU, what is default at reset, etc. If IOs default as floating inputs, then configuring them as outputs (or at least have pull-ups/pull-downs on them, internal or external) is a good idea. Floating inputs usually aren't good. At best, they will usually increase power consumption significantly. Will be particularly noticeable if you're designing a low-power system. OTOH, it would be uncommon IME that floating inputs would make your MCU have erratic behavior, except of course if software actually uses those floating inputs by mistake.

One pin to be careful about, though, is the reset pin. That's one that can cause spurious resets if not properly used and protected (especially in harsh environments.)

Now on some MCUs, IOs simply default as "off", meaning all input buffers can be switched off. In this case, you can leave unused IOs floating. The ability to completely switch off input buffers will yield the lowest power consumption too.

Just read your docs.

[Circlotron]

What about where say port D0-D3 are connected to the outside world but D4-D7 are not, as is often the case with packages that have less pins, and other MCUs in the same family have the full width of the port? Do they use the same die and D4-D7 while not connected to the outside world should also be set as outputs, or do they not exist on the die and can be disregarded? MCS908PAx family.

[Circlotron]

All I know is that when I made those unused pins outputs it finally snapped into action.

Okay, got it sussed now. Was a test jig problem. Had forgotten I had this wire poked into the wire entry end of a spade receptacle and it was occasionally making contact, therefore making a program branch that was quite proper but unexpected.  Oh well...

[Siwastaja]

Unexisting pins you don't need to care about unless the documentation tells you otherwise. It would be a huge trap; never seen it.

[AndyC_772]

It would be hilariously funny, though. "All unused inputs, including those which are not bonded out to physical pins on smaller devices, must be grounded 

[Siwastaja]

Theoretically the pads could exist on the die and not just bonded to a lower pin count package. Then code to set them as outputs would be required. But as far as I have seen, manufacturers do something to prevent this requirement. The dies are not really identical; often there is an ID register as well telling you what exact chip it is. They may have just lasered or burned the fuses of some ROM bits that disable the IO transistors of the unbound pins.

[AndyC_772]

Neither possibility would surprise me!

[SiliconWizard]

Theoretically the pads could exist on the die and not just bonded to a lower pin count package.

Yep. And I guess that happens for some chips that use the same die in various package configurations. But usually in this case, there are internal config 'fuses' to distinguish versions, and the unused pads are disabled internally one way or another. Having to do it programmatically would be pretty odd. Never seen that. But of course, that's physically possible.