I’m using a MCU part with a GPIO pin that is defined as Bidirectional (correctly, if I understand the library rules) but am tying it to either GND which is defined as a Power Output. The ERC is throwing a warning about this. I can clearly ignore this because I want that pin held permanently low so the connection is correct.
Is there a way of correctly defining pins to deal with this scenario such that the warning isn’t flagged?
Use a pull down resistor ?
Edit: I deleted this post as it’s not really relevant to the ERC issue . . . but probably answers the additional point raised, so I’ve undeleted it. Having a bad day today . . . 
There are several ways to overrule this behavior, but before I give any hints, I want you to explain why you think this is a good idea to do.
My only thought was to clear up the warnings that was all. It isn’t absolutely necessary because they are correctly connected but I thought perhaps I’d incorrectly defined something. Given your question, I’m going to assume not!!
Again, why do you think it is correct to connect a “bi-directional” pin from a mcu directly to GND?
It could damage the pin if it’s ever turned on as an (high) output, or at the least cause excessive current consumption (often uC pins are limited to somewere between 20 and 50mA).
It’s fine - it’s been running for years like this, I’m just capturing the schematic in KiCad that was never created originally. On the board there are two MCUs, both PICS, with identical software builds but which do slightly different things. This is governed by a GPIO pin being connected to GND on one MCU and +5V on the other. The software just tests the value of this pin being low or high.
Hi know @paulvdh is going to shout at me (
) but, practically speaking, if this is your only error and you are happy why KiCAD is shouting at you then just ignore it!
A couple of alternatives - a pull down resistor or make a copy to your personal library and edit the pin definition.
(Oh! Is the pin correctly defined in the first place?)
Defined like that in the library and it seems it conforms to the library rules (albeit it might have been an old copy of the rules I found.)
It is an abuse of an I/O pin and the safe solution is to use a series resistor. Even in mass production these cost 0.2 ct or less.
One way to “solve” it is to right click on the ERC message in the ERC and then select “exclude this violation”.
Another way is load your schematic symbol int the symbol editor (just select it and press [Ctrl + e]) and then change the pin type of the offending symbol. Then close the editor, and KiCad prompts you whether you want to update your change in the schematic.
A third way is to change the ERC matrix (Schematic Editor / File / Schematic Setup / Electrical Rules / Pin Conflicts Map) but this affects all bidirectional pins and is the second least recommended method.
The least recommended is to “just ignore it”. If you get into a habit of ignoring warnings and error messages, then they will pile up and you start ignoring the whole warning system in itself. There is also a big chance you miss the more important messages in between the “noise”.
And there are also people who just do not use the ERC system at all. If you do not run ERC, you will also not see ERC messages.
Edit:
Forgot to mention.
You can also (ab)use a net-tie for this. A net tie is a physical part (so it has a PCB footprint etc) but this is just a copper feature, and therefore the only “production cost” is the physical area on the PCB. (or at least it used to be in KiCad V6 and earlier, haven’t used them yet in KiCad V7).
Ok, thanks. Sounds like it isn’t an issue with the pin definition. As for the rest, it is what it is and I’m not going to capture on a schematic, what isn’t there on the board.
It might be worth it to note in your source code that this pin can be hardwired to GND and should never be configured as an output.
Usually I/O pins default to high impedance or input during and after an reset. Have you verified this with your uC?
I hadn’t appreciated this point . . . I think I’d leave the ERC warning happen and maybe add a note with the current date explaining the ERC warning and suggest a pull up/down if the board is modified in the future.
I think (someone may correct me) using a resistor to Gnd will still bring up a warning. ERC is not very clever. Unless an in/out pin is connected directly to another in/out pin there will always be a warning. A resistor is not another in/out pin.
Best to change the in/out pin to passive or change the ERC rules, but still use a resistor.
It shouldn’t, the resistor means that the I/O net is no longer GND and the resistor pin type is passive.
In various company standards I have worked under, connecting I/O to power was strictly forbidden
I once connected all unused uc pins directly to GND. It was pendrive-like device with 32 pin microcontroller and no other digital ICs on board. So the only connections was supply and 2 USB wires (quartz was not needed).
The case was made of 2 parts so ESD could go inside. I wanted all pins that spark could reach to be grounded. The USB connection pins were close to the case center line so other pins were first to be hit by spark. That device passed EMC tests.
It is perfectly fine to hang an IO pin to ground as long as you know what you are doing. If you know for a fact that the pin in question will be high impededant during programming/reset it should be ok.
And ofcouse you should not configure this pin as output in a high state, but again:… if you know what you are doing…
I have always done this for the address pins of I2C IO extenders. I can imagine if you design a board that needs some kind of a hardware address, that you want to do the exact same. You can just configure a pin as input pull-up and tie or not tie it to ground.
Desite a resistor may cost 0.2 cents. It still uses space and if you make a THT design it also needs labouring. In other words: I can imagine that somebody can have reasons not to use a resistor.
Kind regards 
Bas
I can understand, and live with both strains of thought.
If it’s company policy, then it’s simple, comply or get fired or something.
For the other option, It’s not only “if you know what you’re doing”, it’s also long term maintenance, and that is why I suggested to ad a comment in the software (at the point the pin is initialized).
I hadn’t expected a simple question to generate such interest or discussion! The board in question has been running every day, through power cycles, without problem for over 12 years. It’s not a commercial product or anything like that. The question arose because the generated warning is not a situation I’ve come across in other designs I’ve done for myself.
I will say that the chap who created the board, 100% knows what he is doing as he had a lifetime in the electronics industry, designing award-winning video-based technology. I’m documenting it now because he had a very “major boring @£$@@” (to quote The Matrix) approach to that side of things in the context of what the board is used for. Hey ho, Engineers eh.
It’s a different story when it is a product and you want to keep it in production maybe years later. Then you have to think about the possibility of a revised or substitute chip that starts up differently.
Warnings on schematics, in the source code and every design document are essential.
And in such cases you also have to think about getting another job or a promotion and the maintenance for the project being transferred to someone else. And as the hardware has been “stable”, that new guy may be mostly a software person and not know much about electronics.
Sure, it can work, and it can work reliably, but it remains a (potential) error or risk, and KiCad is right to flag it.
Now imagine that a year or two after the “new guy” took over, you start getting complaints from customers of “early battery failure” of the “new and improved” version, and then you realize you have 10000 of these gadgets out in the fields. Such a claim can ruin the whole company. It’s an extreme case, but silly things like this have happened many times before, and that is why things like this are “simply not allowed” in the company davidrsb works. Interesting note: In case of an added series resistor, there would still be an excessive battery drain (although slower).