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.