My microcontroller board does not show up as a serial port at all — no port to select, on any computer

The power LED lighting up tells you less than it seems: the power pins in a USB cable are separate from the data pins, and a cable can carry one without the other. That is the first thing to rule out and it is the most common cause by a distance.

Work down this list in order. It is roughly ordered by how often each one turns out to be it.

1. A charge-only cable. Cables that came with a power bank, a battery pack or a set of headphones very often have no data lines at all. The board powers up and looks alive and the computer never sees a device. Find a cable you have definitely used to transfer data — one that came with a phone for syncing, or one you have used with another board — and try that first. This is the single highest-yield check and it costs nothing.

2. No driver for the USB-to-serial chip. Most development boards do not speak USB themselves. They carry a separate bridge chip that converts USB to serial, and that chip needs a driver. There are a handful of common ones and they need different drivers. Clone boards very often use the cheapest bridge, which is precisely the one least likely to be installed already.

How to tell: look at your operating system's device list — device manager, the system report, or the kernel log after plugging in. If a device appears at all, even as an unknown or error-flagged one, it is a driver problem and the board is fine. If nothing appears anywhere on plug-in, go back to step one.

On Linux the common bridges are supported in-kernel and you generally need no driver at all, which changes what to suspect — see below.

3. On Linux specifically, two things that are not drivers:

• Permissions. The port exists but your user cannot open it, so the IDE shows nothing usable. The fix is adding your user to the group that owns serial devices, then logging out and back in, which is the step people skip and then conclude it did not work.
• A screen-reader daemon claiming the device. One widely-installed accessibility service grabs a particular common bridge chip on sight, because a braille display uses the same chip. The port appears for a second and vanishes. If your kernel log shows the device attaching and then being detached, this is it. Removing or disabling that service fixes it permanently.

4. A board with native USB, in the wrong state. Newer chips implement USB directly rather than through a bridge. On those, the port is created by firmware running on the chip — so a board with no firmware, or firmware that crashed, or one sitting in a bootloader mode that presents differently, will not appear as the port you expect. Some of these boards need a manual reset, or a double-tap of reset, to present the bootloader.

5. A hub or a front-panel socket. Try a socket directly on the machine, at the back on a desktop. Unpowered hubs and some front panels are unreliable for this.

Order of operations if you want to be quick: different cable, then look at the device list on plug-in. Those two together identify the cause in the large majority of cases, and everything else on this list is downstream of what they tell you.

On the driver step, one warning that costs people an evening: install the driver from the chip manufacturer, not from whichever download site ranks well.

Counterfeit bridge chips are common on cheap boards, and there has historically been an ugly cat-and-mouse where a driver update deliberately refuses to work with clones. So a board that worked can stop working after an operating system update, which looks exactly like hardware failure.

If you hit that specific case — worked before, dead after an update, device appears with an error code — the answer is usually an older signed version of the driver. Which is annoying, but it is a known situation rather than a mystery.

Also: on macOS, driver installs of this kind usually need explicit approval in the security settings, and if you miss the prompt the install silently does nothing. Check there before reinstalling for the third time.

Cheap way to prove the board is not dead, if you have any second device: plug it into a phone with an adapter, or a tablet, or a different machine at work.

The point is not to use it there, only to see whether anything enumerates. If another device sees it, the board and cable are fine and you are debugging one computer. If nothing sees it anywhere, you have narrowed it to the board or the cable, and swapping the cable is the cheaper test of those two.

Splitting the problem across the USB boundary first saves a lot of guessing. Almost nobody does it because it feels like a detour, and it is usually the fastest route.