cancel
Showing results for 
Search instead for 
Did you mean: 

B-U585I-IOT02A: A Documentation and Hardware Minefield

islavv
Visitor

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.

1 REPLY 1
TDK
Super User

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?

TDK_1-1754421124424.png

TDK_0-1754421081690.png

If you feel a post has answered your question, please click "Accept as Solution".