Vision board WiFi connection failed: firmware and variant fixes

An embedded vision board that boots, runs your sketch and then loops forever on "Attempting to connect to SSID" is rarely broken hardware. The failure almost always sits in one of three places: stale radio firmware, an out-of-date bootloader, or the wrong board variant selected at upload. The sketch itself is usually fine — it is asking a radio that cannot answer yet. This page gives the fix order: read the serial signature first, update the radio firmware and bootloader the documented way, clear the board-variant trap, then work through antenna, band, credentials and DHCP checks, and finish with a scan test that tells you whether the module itself is at fault. It is written for engineers bringing WiFi up on a camera or vision board with a built-in radio.

Read the serial output before touching anything

The console narrows the fault to one layer before you change a single setting. Three signatures cover nearly every case.

1. "Communication with WiFi module failed!" — WiFi.status() returned WL_NO_SHIELD. The library cannot talk to the radio at all. The sketch died at its module check, before credentials were ever used, so no SSID or password edit can fix it. Work through the firmware, bootloader and board-variant sections below.

2. The sketch loops forever on "Attempting to connect to SSID: ...". WiFi.begin(ssid, pass) runs, the radio answers, but the result never reaches WL_CONNECTED — status stays at WL_IDLE_STATUS while the 3-second delay(3000) retry loop grinds on. Association is failing: band mismatch, security mode, invisible characters in the credentials, or an access-point feature rejecting the client. Work through the network-side list.

3. It prints "Connected to wifi", then client.connect(server, 80) fails. The radio link is fine; the fault is one layer up. Print WiFi.localIP(): 0.0.0.0 means no DHCP lease arrived. If the address is real, test the server by numeric IP before blaming DNS or the board. The DHCP failure mode and its static-IP workaround are in static IP for a firmware update: why DHCP blocks it, with the general first-connection checks in connect a depth camera over IP.

From here on, change one thing at a time — the same discipline as embedded camera bring-up: isolate integration failures.

Update the radio firmware with the vendor's updater sketch

The radio chip runs its own firmware, separate from your sketch, and boards ship with it stale more often than with any other part missing. Packages for these boards include a documented updater sketch among the examples that come with the WiFi library.

1. Find the firmware updater sketch in those examples and open it.
2. Upload it exactly like any sketch: the updater is itself a sketch that compiles, loads and rewrites the radio firmware while the serial monitor prints progress.
3. Let it run to completion, which takes minutes, and note the version it reports at the end.
4. Re-upload your own sketch and test the connection again.

Treat the update like any sensor firmware job and record the version the updater reported, so a later "it worked yesterday" has a baseline. The readback discipline from the camera firmware update workflow applies unchanged, and boards that update over a USB boot mode follow the same rules as the depth camera DFU update.

Update the bootloader before blaming the library

The same documentation that covers the radio updater usually includes a bootloader-management example among the board's system examples. Upload that first, then the radio firmware, then test — that order resolves the stubborn cases. Some boards also want a double-press of the reset button to enter bootloader mode before an update; the guide says when. In the reverse order, a new radio image can land on an old bootloader with the symptom unchanged.

The board-variant trap: two menu entries, one board

This is the most common software cause of a WL_NO_SHIELD that survives a clean firmware update.

Development tools that manage boards by package often list the same physical board twice: once under a generic operating-system package and once under the board family's own package. Both entries compile your sketch without errors and both upload it, so nothing looks wrong. But the two builds reach the radio through different drivers, and the generic build never gets an answer — WiFi.status() stays at WL_NO_SHIELD even though the updater reported success minutes earlier.

The fix takes ten seconds. In the board selector, choose the entry belonging to the board family rather than the generic package, re-upload the sketch, and test. If the console message changes from "Communication with WiFi module failed!" to an association attempt, the variant was the fault.

Clear the network side in this order

Association failures — signature 2 above — fall to these checks, most likely first:

1. Antenna seating. The small coax connector seats with a light press; half-seated works at one metre on a bench and fails at ten metres inside a cabinet. Press it home, stand the antenna vertical, and keep it 5 cm or more from metal: a 2.4 GHz wave is only about 12.5 cm long (3×10^8 m/s ÷ 2.4×10^9 Hz ≈ 0.125 m), so a nearby bracket acts as mirror and loss path at once.
2. Band. Modules in this class are commonly 2.4 GHz-only, and a 2.4-only radio can never join a 5 GHz-only network; no update changes that. Test with a phone hotspot — most let you fix the hotspot band to 2.4 GHz — and keep the machine link on 2.4 GHz: it carries through walls better than 5 GHz.
3. Credentials. For the first test, type the SSID and password as plain letters and digits inside straight quotation marks in your credentials header. Pasted text carries invisible failures: a non-breaking space or a curly quote looks identical in the console and never matches the network.
4. Security mode. Stacks in this class generally speak WPA/WPA2; an access point set to WPA3-only rejects them. Set the AP to WPA2 or mixed mode for the test.
5. Access-point features. MAC filtering, client isolation and per-client limits all look identical from the board — WiFi.begin() fails with correct credentials. Switch them off for one test.

Worked example: is the signal strong enough

Once the board associates, WiFi.RSSI() reports received strength in dBm, and those numbers decide whether the link holds. Case: a board inside a steel enclosure reads -78 dBm at its mounting point; with the antenna moved two metres, outside the metal, it reads -52 dBm.

Every 10 dB is a factor of ten in received power and every 3 dB a factor of two, so the re-routed antenna delivers roughly 400 times more signal at the radio. The thresholds used in Wi-Fi planning: -50 to -67 dBm is comfortable; -70 dBm is workable for small periodic payloads; -80 dBm and below is where association timeouts and retries dominate — the classic "connects now and then, then vanishes for a day" pattern. Decision: when two metres of antenna lead and clear air buy 20 dB or more, re-route the antenna and re-seat the coax; the module is not the problem.

A scan test splits the fault in half

When firmware, bootloader and variant are current and the board still refuses, upload a scan sketch: a dozen lines that start serial, call the library's scan-for-networks function, print every network found, and repeat every ten seconds. Nothing else in it.

• The scan lists networks — ideally the same list your phone shows standing next to the board. The library-to-radio path works, so the fault is credentials, band or access-point configuration; go back to the network-side list.
• The scan lists nothing while the phone sees a dozen — the library-to-radio path is still broken, and garbled scan output counts as the same verdict. Re-check the board variant, then update bootloader and radio firmware once more, in that order.

That single test separates a software-stack fault from radio hardware, which is why it is the last gate before declaring the module damaged.

When to stop debugging and go wired

If the updater ran clean, the bootloader is current, the family variant is selected, the antenna is seated, and the scan still finds nothing beside a phone that sees a dozen networks, the module or its antenna feed is faulty. Radio damage is rare but real, and it usually arrives through wiring or supply faults — the triage steps in camera GPIO wiring: prevent damage and triage power faults apply to radio modules too. Take the replacement path with the board vendor's support instead of another firmware round.

For a production vision cell, WiFi is usually the wrong link even when it works. Plant RF is shared with phones, vehicles and neighbouring machinery, and the inspection loop wants deterministic timing. Put the camera on wired GigE and run the cell from a controller with enough LAN ports and built-in light channels: the vision controllers category starts at compact single-camera boxes and goes up to multi-port machines, and GigE board-level cameras drop into tight spaces as wired camera heads. The bandwidth math for multiple WiFi cameras on one embedded board shows why a shared RF link rarely carries a real frame budget. More link-layer and bring-up procedures sit on the systems topic page.

Two controllers that cover the wired path from a compact cell upward:

The MV-VC2140-128G40-1T is the compact option, built on an Intel N-series processor with 8 GB memory, 3-4 LAN ports and 4 built-in light channels. The MV-VC3301H-128G66 moves up to an Intel Core i3 with 5+ LAN ports for cells that keep adding cameras. If the camera head itself must be small, a 1.6 MP GigE board-level camera such as the MV-CB016-10GM-M-W pairs a global-shutter 1/2.9-inch sensor with an M12 mount, on a wired link that ignores plant RF.

Sizing camera, lens, controller and light channels together, the configurator walks the choices in order. If you want a person to check the plan before ordering, contact the applications team. And when a camera head is destined for a machine interior rather than a bench, the board camera evaluation checklist covers the industrial criteria first.

Checklist before you blame the module

Software stack

• Radio updater ran to completion and printed its version — a partial update is the most common false "it is updated".
• Bootloader example uploaded before the radio firmware — the order that resolves stubborn cases.
• Board-family package selected at upload, not the generic one — the top software cause of WL_NO_SHIELD.

Radio and RF

• Antenna coax pressed home, vertical, 5 cm or more from metal.
• Phone hotspot on 2.4 GHz connected — proves module, stack and credentials end to end.
• Scan sketch sees the same networks as the phone beside the board.

Network

• Credentials are letters and digits in straight quotes, typed rather than pasted.
• AP on WPA2 or mixed mode, with MAC filtering and client isolation off for the test.
• WiFi.localIP() shows a real address, and the server answered a numeric-IP test before any DNS name was tried.

Then

• Pace retries at 5-10 seconds with a bounded attempt count, so a failing link prints diagnostics instead of hanging the sketch in a delay(3000) loop.
• Feed the board from a supply rated for its transmit peaks, not its idle draw: radio bursts sag weak USB ports and reset boards mid-association.
• Every check above passed and scan still finds nothing — declare the module faulty, arrange the replacement through the board vendor, and run the cell on wired GigE.