2025-08-05 11:53 AM
B-U585I-IOT02A: A Documentation and Hardware Minefield
Authorship below is AI but we toutured board together in order to run through STM samples and none of them worked properly
The B-U585I-IOT02A is sold as a turnkey combo for BLE (STM32WB) and Wi-Fi (MX3080), but in reality
you’re left digging through conflicting silkscreen legends, empty headers, and no-op switch nets.
Here’s why the out-of-box experience is a complete mess.
1. Mis-labeled Console Headers
- CN12 touted as “BLE Console”
• No TX/RX from the STM32WB network core ever appear here.
- True console seems to be CN1 (USB-C) in DFU/VCP mode via dfu-util
• You must boot the U5 application (BOOT0=0) and use the USB-C port to see the bridge-firmware’s virtual COM.
2. SW1, SW2, SW3: All Talk, No Walk
Every switch on this board toggles nets that never do what the silkscreen or manual claim:
| Switch | Silk Legend | Doc Says | Actual Result |
| SW1 | BOOT0 ↔ NC_BOOT | BOOT0=1 → system loader boot | No pull-up resistor fitted → BOOT0 always = 0 |
| SW2 | NC_ESLK ↔ ESLK | NC_ESLK to isolate ST-LINK for DFU | Correctly breaks SWD, but legend “0/1” obscures net names |
| SW3 | ? (Wi-Fi console?) | Toggle to route MX3080 debug UART | No UART traces connected to any header |
- SW1 never drives BOOT0 high because R25 (pull-up) is unpopulated.
- SW3 exists only as a placeholder — its nets go nowhere.
3. Nightmare Firmware-Loading Paths
- BLE (STM32WB)
- You expect CN12 UART → network core logs. Instead you must build and flash a USB-bridge image into the U5, boot application, then connect CN1.
- Wi-Fi (MX3080)
- No dedicated X-NUCLEO shield: you wire SDIO manually or use the Discovery’s onboard MX3080.
- Docs refer to switch positions that don’t actually change reset, wake, or power-enable lines. You have to probe nets and rig GPIO toggles in firmware.
- Co-existence
- No single instruction set for bringing up BLE, Wi-Fi, and your app in one flow. You juggle Boot0, ST-LINK isolation, USB-DFU, custom U5 bridge firmware, then manual SDIO init.
4. Core Design Flaws
- Empty headers (SW3 path, CN12) give false hope for direct console or debug.
- Switches are silk-screened with net names, not “0/1 = off/on,” making “set position X” instructions meaningless.
- Critical pull-up/pull-down components are missing or mis-assigned, so no hardware path ever does what the docs claim.
- CM4 and CM5 MCU debug switches are missing on board
5. How It Should Be
- Proper pull-up and pull-down resistors fitted for BOOT0, with SW1 as a true SPDT between them.
- SW3 routed to MX3080 UART_TX/RX and documented in silkscreen.
- Clear instructions: “Use CN1 for BLE logs,” “SW1 = position 1 for DFU, 0 for app boot,” “SW2 connects ST-LINK for debugging.”
- A combined firmware-load script or utility image for U5 that handles both BLE and Wi-Fi flashing over USB-DFU.
6. stm32wb5x_BLE_Stack_full_fw.bin in distribution of firmware is .html/text file and becaues not working. other light version seems bin file but not operates
and _extended does not load by size.
Bottom Line
Out of the box, the B-U585I-IOT02A feels like an early prototype masquerading as a production board. The silkscreen legends, switch logic, and header pinouts do not match the manual. Flashing BLE and MX3080 Wi-Fi together requires hardware mods, bridge-firmware hacks, and a lot of trial and error. Buyer beware.
2025-08-05 12:13 PM
The schematic is provided. In the schematic, SW1 and SW3 are connected as described. R25 isn't relevant to SW1. AI hallucinating? Are these actual discrepancies or just made up stuff?