@ElektrodaBot How to flash BL602 with OpenBK AI: What hardware or connection method are you using to connect the BL602 to your computer (e.g., USB-to-serial adapter, specific dev board)? USB to serial AI: What operating system are you using (Windows, Linux, or macOS)? Ubuntu - Linux
@ElektrodaBot how to flash bl602 with openbk AI: What hardware or connection method are you using to connect the BL602 to your computer (e.g., USB-to-serial adapter, specific dev board)? usb to se...
Initial assessment of available information - You’re on Ubuntu and will use a USB‑to‑serial adapter. The BL602 can be flashed reliably over UART if you strap BOOT (GPIO8) correctly and use the right UART pins and baud rate. - The correct boot strap for BL602 flashing mode is: GPIO8 pulled HIGH (to 3.3 V) during reset/power‑up. Several online guides mistakenly say “BOOT to GND” (that’s true for some Espressif parts, not for BL602). On BL602 the ROM bootloader listens on UART0 with RX on GPIO7 and TX on GPIO16. (lupyuen.github.io) - The OpenBeken project publishes ready‑to‑flash BL602 images on every release. As of 2025‑10‑05 the latest is 1.18.188 with assets “OpenBL602_1.18.188.bin” (UART flash) and “OpenBL602_1.18.188_OTA.bin.xz.ota” (OTA). (github.com) - For flashing tools on Linux, Bouffalo’s CLI “bflb‑mcu‑tool” is current and maintained on PyPI; “blflash” (Rust) also works if you prefer it. BLDevCube GUI is another option. (pypi.org)
Direct answer to the question Below is a minimal, working procedure to flash OpenBeken (OpenBK) onto a BL602 over USB‑to‑serial on Ubuntu:
1) Wiring (3.3 V only, not 5 V) - GND → GND - 3V3 → VDD (stable 3.3 V supply) - Adapter TX → BL602 RX (GPIO7) - Adapter RX → BL602 TX (GPIO16) - BOOT (GPIO8) → pull up to 3.3 V during power‑up/reset (prefer 10 kΩ). (elektroda.com)
2) Put BL602 in flashing mode - With power off, strap GPIO8 to 3.3 V (keep it high), then power up or reset. (lupyuen.github.io)
4) Download OpenBeken for BL602 - Get the latest “OpenBL602_….bin” from the project’s Releases (UART Flash asset). (github.com)
5) Flash - Typical fast attempt: bflb-mcu-tool --chipname bl602 --port /dev/ttyUSB0 --baudrate 2000000 --firmware OpenBL602_x.y.z.bin - If you see “Not ack OK/timeout”, retry at a lower baudrate, e.g. --baudrate 115200 or 200000. (pine64.github.io)
6) First boot - Remove the BOOT strap (GPIO8 no longer forced high) and power‑cycle. The device should start OpenBeken and create an AP like OpenBL602_XXXX; connect and browse to 192.168.4.1 to configure Wi‑Fi. (coreforge.com)
If you prefer, you can use BLDevCube GUI (Linux build) with Interface=UART and 2 Mbps as the recommended rate; many adapters work more reliably at 115200–200000 baud. (pine64.github.io)
Detailed problem analysis - Boot strap and UART pins - The ROM loader on BL602 uses UART0 at GPIO7 (RX) and GPIO16 (TX). That’s why adapters wired to “typical” pins like GPIO14/15 won’t talk to the boot ROM during flashing. Ensure the crossover: adapter TX → GPIO7, adapter RX → GPIO16. (lupyuen.github.io) - Entering the loader requires BOOT (GPIO8) HIGH at reset/power‑up; several vendor boards expose this as “IO8 H/L” jumper. Keep it high, then reset. (lupyuen.github.io)
- Tools - bflb‑mcu‑tool (PyPI) mirrors DevCube’s MCU flashing flow on the command line and is actively maintained (v1.10.x in 2025). Start at 2 Mbps if your adapter is known‑good; otherwise fall back. (pypi.org) - BLDevCube (GUI) is Bouffalo’s official tool; Pine64 docs show the UART workflow. It defaults to 2 Mbps and can be slow to start; if you get UART errors, reduce to 115200–200000. (pine64.github.io) - blflash (Rust) is widely used by developers; it flashes a prepared image over UART and supports setting separate initial and main baud rates. (github.com)
- Image selection and addressing - Use the OpenBeken “BL602 UART Flash” .bin from Releases. It’s prepared for the standard UART flashing flow; you don’t need to manually compose Boot2/partition/DTS. (github.com) - If you use BLDevCube’s advanced pages, ensure the partition config matches your flash size (most consumer BL602 devices are 2 MB; using an incorrect table can prevent boot). If you’re unsure, back up first. (elektroda.com)
- Baud rate reality check - Docs recommend 2 Mbps, but in practice cheap CH340/CP2102 adapters and long leads can drop packets. If you get “Not ack OK” or retries, try 115200–200000 baud; it’s slower but reliable. (pine64.github.io)
- Power - Provide a stable 3.3 V supply. Some adapters can’t source enough current for Wi‑Fi bring‑up; use a proper 3.3 V LDO if you see brownouts (boot loops when AP starts). (elektroda.com)
Current information and trends - Latest OpenBeken release (as of 2025‑10‑05): 1.18.188 with BL602 assets “OpenBL602_1.18.188.bin” (UART) and “…_OTA.bin.xz.ota” (OTA). (github.com) - bflb‑mcu‑tool on PyPI shows active updates in 2025 (1.10.x). (pypi.org)
Supporting explanations and details - Why BOOT=HIGH? - The BL602 ROM checks GPIO8 at reset to select the ISP/loader. HIGH selects UART flashing, LOW continues normal boot. Vendor EVBs expose an IO8 “H/L” jumper for this reason. (lupyuen.github.io) - Why GPIO7/16? - The ROM’s default device tree/config maps UART0 RX/TX to GPIO7/GPIO16 at high baud; that’s what the loader expects before your firmware remaps anything. (lupyuen.github.io)
Practical guidelines (Ubuntu walkthrough) 1) Permissions - Add yourself to the serial group and re-login: sudo usermod -a -G dialout $USER - Identify the adapter: dmesg | grep -i tty ls -l /dev/ttyUSB*
2) Install tool and get firmware - python3 -m pip install --user bflb-mcu-tool - Download OpenBL602_x.y.z.bin from the Releases page (BL602 “UART Flash” asset). (pypi.org)
3) Wire and enter flashing mode - GND, 3V3, TX↔RX (TX→GPIO7, RX→GPIO16), BOOT (GPIO8) → 3.3 V. - Power up or press reset with BOOT held high. (elektroda.com)
4) Flash - Fast try: bflb-mcu-tool --chipname bl602 --port /dev/ttyUSB0 --baudrate 2000000 --firmware OpenBL602_x.y.z.bin - If handshake fails: bflb-mcu-tool --chipname bl602 --port /dev/ttyUSB0 --baudrate 115200 --firmware OpenBL602_x.y.z.bin (Optionally add --erase to wipe flash before programming.) (pypi.org)
5) First boot - Remove BOOT strap, power‑cycle. - Connect to AP “OpenBL602_…” and browse to 192.168.4.1 to provision Wi‑Fi. (coreforge.com)
Optional alternatives: - BLDevCube (GUI): Select BL602/604, Interface=UART, Port=/dev/ttyUSB0, Baud=2 000 000 (or 115200 if needed), load the BL602 UART Flash .bin in the firmware field, then program. (pine64.github.io) - blflash: ./blflash flash OpenBL602_x.y.z.bin --port /dev/ttyUSB0 (Use --initial-baud-rate/--baud-rate if you need to slow down.) (github.com)
Troubleshooting - Tool can’t open /dev/ttyUSB0: ensure you re‑logged after adding dialout or run with sudo once. - “Not ack OK”, “timeout”, or repeated retries: lower baud, shorten wires, and use a better 3.3 V supply. (elektroda.com) - No AP after flashing: confirm BOOT strap is removed; power‑cycle; if still no AP, re‑flash at lower baud, and verify your partition table matches flash size if you went through DevCube advanced pages. (elektroda.com) - Backup/restore: before changes, you can read the entire flash with BLDevCube via UART (use ~200 kbaud if 2 Mbaud is unstable; for 2 MB devices read length 0x1FFFFF). (elektroda.com)
Ethical and safety aspects - Disconnect mains completely when working on in‑circuit devices (bulbs, sockets). Never power the device from mains and the UART rig at the same time.
Possible disclaimers or additional notes - Some BL602 boards (PineCone, DT‑BL10) expose boot/reset controls; follow the board‑specific sequence if available (e.g., set IO8 jumper “H”, press RESET). (lupyuen.github.io)
Suggestions for further research - If your device is a MagicHome/CozyLife BL602 and you’d rather avoid soldering, there’s a documented OTA method using the OTA asset (…_OTA.bin.xz.ota). This uses the vendor’s update channel by serving the file locally. (elektroda.com)
Brief summary - Wire GND/3V3 and cross TX/RX to GPIO7/16; pull BOOT (GPIO8) HIGH and reset to enter ROM loader; flash the latest OpenBL602 UART .bin with bflb‑mcu‑tool (or BLDevCube/blflash); remove BOOT and reboot; join the OpenBL602 AP to configure. (lupyuen.github.io)
Questions for the user - Which exact BL602 device/board is this (module marking or product model)? I can provide a ready OpenBeken template (GPIO roles) for your hardware once I know the model.
You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
Initial assessment of available information - Your flashing log shows a complete, verified program of OpenBL602_1.18.187.bin to a BL602 with 2 MB flash (JEDEC EF4015). The tool created boot header, erased the needed regions, wrote the image, and verified SHA-256 — “All Successful”. So the image is in flash. (pypi.org) - On BL602, the boot mode is selected by GPIO8 (BOOT). GPIO8 HIGH at reset enters the UART ROM loader; GPIO8 LOW or floating at reset boots from flash. If BOOT remains HIGH after flashing, the chip will sit in the loader and never start OpenBeken (hence no AP). (pine64.github.io) - On first normal boot, OpenBeken for BL602 starts a 2.4 GHz Soft‑AP named “OpenBL602_<last 3 bytes of MAC>” on 192.168.4.1. In your log the MAC is d9:5b:1b:94:94:24, so expect an SSID like OpenBL602_949424. (coreforge.com)
Direct answer to the question Most likely causes and the fastest fixes: 1) Remove the BOOT strap and power‑cycle - Disconnect GPIO8 from 3.3 V, then press RESET or power off/on. This is the number‑one reason for “flash OK, but no AP.” (pine64.github.io) 2) Power the module from a stable 3.3 V source (≥300 mA) - Don’t rely on the 3.3 V pin of a USB‑to‑serial dongle for Wi‑Fi bring‑up; brownouts cause silent boot loops and you won’t see an AP. (elektroda.com) 3) Watch the boot log at 115200 bps - With BOOT released, open “screen /dev/ttyUSB0 115200” or “minicom -D /dev/ttyUSB0 -b 115200” and power‑cycle. You should see the OpenBeken banner and AP start messages; if not, note any errors. 4) If still nothing, re‑flash with a full chip erase - bflb-mcu-tool --chipname bl602 --port /dev/ttyUSB0 --baudrate 115200 --erase --firmware OpenBL602_1.18.187.bin (remind: BOOT must be HIGH only for flashing, then LOW to run). (pypi.org) 5) If your board’s crystal is not 40 MHz, set the right XTAL when flashing - For example, for a 26 MHz crystal add “--xtal 5”. Using the wrong XTAL in the boot header can prevent Wi‑Fi from initializing. (pypi.org)
Detailed problem analysis - Boot strap state (most common) - Your log proves the UART loader worked, which requires GPIO8=HIGH. If that strap stays in place after flashing, BL602 re-enters the loader at every reset and never executes the app. Remove the strap (or set the board’s jumper to “L/LOW”), then reset. (pine64.github.io) - Power delivery during radio bring‑up - Wi‑Fi enable causes short current spikes. Many CH340/CP2102 adapters can program reliably but sag on 3.3 V during AP start, leading to brownouts and invisible AP. Power the module from a proper 3.3 V regulator (GNDs common with the USB‑UART). If you see the serial banner repeating, that’s a boot loop from undervoltage. (elektroda.com) - What SSID to look for and how to scan - Default SSID is “OpenBL602_<MAC>” on 2.4 GHz. With your MAC, search for “OpenBL602_949424”. On Ubuntu: - nmcli dev wifi rescan; nmcli -f SSID,SIGNAL dev wifi | grep -i openbl602 - Or sudo iw dev wlan0 scan | grep -i openbl602 - Try a phone scan in case your Linux card/regulatory domain is filtering channels. Default Soft‑AP channel is a standard 2.4 GHz channel; if your region disallows ch12/13 and the AP selected it, visibility can depend on client regdom. (coreforge.com) - Residual configuration in flash - A previous config (from earlier tests) might make the device try STA mode only and not expose AP. Do a full erase re‑flash (add --erase) so NVM/config partitions are cleared, then boot fresh. (pypi.org) - XTAL mismatch (less common but real) - bflb-mcu-tool generated an image with default 40 MHz boot header (and used eflash_loader_40m). If your module actually has a 26 MHz crystal, Wi‑Fi init may fail. Re‑flash with the correct XTAL option: - 24M=1, 32M=2, 38.4M=3, 40M=4 (default), 26M=5. Check the crystal can marking (often “40.000” or “26.000”). (pypi.org) - Serial lines and control signals - After flashing, some adapters keep DTR/RTS asserted (“default set DTR high” is in your log). On some boards these lines are wired to reset/boot circuits. For the first run test: leave only 3.3 V and GND connected, or at least ensure your terminal program deasserts DTR/RTS. - Partitioning expectations - Your log shows the standard map (bootinfo @0x_0, app @0x2000) used by Bouffalo tools; OpenBL602 UART binaries are built for exactly that. A mismatched partition table is unlikely here, but if you used “advanced” options before, return to defaults or erase fully. (pine64.github.io) - Antenna/hardware faults - Even with no antenna, at close range you normally still see an SSID. No SSID plus no boot log often traces back to BOOT strap or power.
What you should see on the serial console (normal case): - OpenBeken banner, MAC, then messages about starting Soft‑AP; afterward the SSID “OpenBL602_…”. This behavior (first boot exposes Soft‑AP on 192.168.4.1) is documented and reported by users. (coreforge.com)
If AP still doesn’t appear after the above: - Force AP from the console: connect GND and BL602 TX (GPIO16) to your USB‑UART RX, open 115200 and enter commands: - Backlog WiFi_EnableAp 1; WiFi_SSID OpenBL602_Test; WiFi_Pass 12345678; Save; Restart This mirrors the HTTP/CLI grammar used by OpenBeken (WiFi_SSID, WiFi_Pass, WiFi_EnableAp, Save, Restart). (elektroda.com) - Try a different build (same major) in case of a local image issue; 1.18.187 is a current release line, and OpenBeken publishes ready-to-flash OpenBL602 images in Releases. (newreleases.io)
Current information and trends - OpenBeken releases include OpenBL602 UART images; 1.18.187 is among the latest tagged releases as tracked by release aggregators. (newreleases.io) - Bouffalo’s CLI bflb‑mcu‑tool (PyPI) remains the recommended open flasher; it supports full chip erase and explicit XTAL selection for BL602. (pypi.org) - Community reports confirm default AP naming “OpenBL602_<MAC>” and first‑boot Soft‑AP workflow. (coreforge.com)
Supporting explanations and details - Why BOOT must be LOW to run: BL602’s ROM checks GPIO8 at reset; HIGH selects UART ISP, LOW/FLOAT selects flash boot. That is the vendor‑documented flow used by BLDevCube and mirrors your flashing steps. (pine64.github.io) - Why power matters: flash programming is tolerant to low current, but radio start is not. A weak 3.3 V source lets you flash fine but fails at AP bring‑up. (elektroda.com) - Why the XTAL setting matters: the boot header/config tells the SDK the reference frequency; wrong frequency can break RF calibration and timing. bflb‑mcu‑tool lets you set this explicitly. (pypi.org)
Practical guidelines (Ubuntu) - Permissions: sudo usermod -a -G dialout $USER; re‑login. - Serial monitor: screen /dev/ttyUSB0 115200 (Ctrl‑A, K to quit) or minicom -D /dev/ttyUSB0 -b 115200. - Full erase re‑flash (if needed): bflb-mcu-tool --chipname bl602 --port /dev/ttyUSB0 --baudrate 115200 --erase --firmware OpenBL602_1.18.187.bin Add --xtal 5 if your crystal is 26 MHz. (pypi.org)
Ethical and safety aspects - If this module is inside a mains device (bulb/plug), disconnect from mains during UART work. Never power from mains and UART at the same time.
Suggestions for further research - If your router uses WPA2/WPA3 transition or PMF required and later you see association issues in STA mode, test with WPA2‑only to isolate BL602 SDK quirks reported by users; but this is unrelated to AP creation. (elektroda.com)
Brief summary - The flash was good. Remove the BOOT (GPIO8) pull‑up, power the board from a solid 3.3 V supply, and watch the 115200‑baud console on first boot. You should see and be able to join “OpenBL602_949424” on 192.168.4.1. If still no AP, re‑flash with --erase (and the correct --xtal if your crystal isn’t 40 MHz) and/or force AP via the serial commands. (pine64.github.io)
Questions for the user - After flashing, was GPIO8 still tied to 3.3 V when you tried to look for the AP? - What module/board is this (photos or crystal marking would help confirm 26 MHz vs 40 MHz)? - How are you powering the BL602 during the “no AP” test? - Can you paste the first 50–100 lines from the serial console after you remove the BOOT strap and power‑cycle?
You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
after flashing removed the 3v3 from p8 used external 3v3 removed wire plus removed the serial adapter from USB put wire to 3v3 plus put the serial adapter started screen did power cycle no output on screen the controller is BL602L
Added after 58 [seconds]:
>>21713120 after flashing removed the 3v3 from p8 used external 3v3 removed wire plus removed the serial adapter from USB put wire to 3v3 plus put the serial adapter started screen did power cycle no output on screen the controller is BL602L
Added after 53 [seconds]:
@ElektrodaBot after flashing removed the 3v3 from p8 used external 3v3 removed wire plus removed the serial adapter from USB put wire to 3v3 plus put the serial adapter started screen did power cycle no output on screen the controller is BL602L
after flashing removed the 3v3 from p8 used external 3v3 remove wire plus removed the serial adapter from usb
put wire to 3v3 plus put the serial adapter started screen did power cycle no output on screen the controller is bl602L
Added after 58 :
after flashing removed the 3v3 from p8 used external 3v3 remove wire plus removed the serial adapter from usb
put wire to 3v3 plus put the serial adapter started screen did power cycle no output on screen the controller is bl602L
Added after 53 :
@ElektrodaBot after flashing removed the 3v3 from p8 used external 3v3 remove wire plus removed the serial adapter from usb
put wire to 3v3 plus put the serial adapter started screen did power cycle no output on screen the controller is bl602L after flashing removed the 3v3 from p8 used external 3v3 remove wire plus removed the serial adapter from usb
put wire to 3v3 plus put the serial adapter started screen did power cycle no output on screen the controller is bl602L
Added after 58 :
after flashing removed the 3v3 from p8 used external 3v3 remove wire plus removed the serial adapter from usb
put wire to 3v3 plus put the serial adapter started screen did power cycle no output on screen the controller is bl602L
Added after 53 :
@ElektrodaBot after flashing removed the 3v3 from p8 used external 3v3 remove wire plus removed the serial adapter from usb
put wire to 3v3 plus put the serial adapter started screen did power cycle no output on screen the controller is bl602L
Initial assessment of available information - Your flash session finished with “[All Successful]” and valid SHA-256, so the image is on flash and the external SPI (EF4015, 2 MB) is detected correctly. The tool also built a 40 MHz boot header by default. (pypi.org) - To boot from flash, BL602 must see BOOT/IO8 LOW or floating at reset; BOOT HIGH keeps the chip in the UART ISP and your app will never run. (pine64.github.io) - The ROM loader uses UART0 on GPIO7 (RX) / GPIO16 (TX) for flashing. Many BL602 firmwares (including SDK examples) move the runtime log/console to a different UART/pins (commonly UART1 on GPIO4 TX / GPIO3 RX at 115200), so you won’t see any boot messages if you keep listening on GPIO16 after flashing. (lupyuen.org) - OpenBeken Soft‑AP for BL602 can come up on 192.168.169.1 (not 192.168.4.1 like other chips), so keep that in mind when testing AP. (github.com)
Direct answer to your situation Given “no serial output” after a verified flash and that you’re on a BL602L with an external 3.3 V supply, the three most probable causes are: 1) You’re monitoring the wrong UART pin for logs. After flashing on GPIO7/16, move your USB‑UART RX to the app’s TX pin (try GPIO4 TX at 115200 first; if nothing, try GPIO16 at 2,000,000 and 115200). (pine64.github.io) 2) XTAL mismatch. Many BL602L modules ship with a 26 MHz crystal; you flashed with the default 40 MHz header. Re‑flash with a full erase and the correct XTAL parameter. (pypi.org) 3) Missing common ground. When you power the module from an external 3.3 V source and read serial via a USB adapter, all grounds must be tied together (PSU GND, module GND, USB‑UART GND). Otherwise you’ll see no UART output even if the MCU is running.
Detailed problem analysis - UART pins versus flashing pins - The BL602 ROM’s ISP strictly listens on UART0 at GPIO7/16. That’s why the flasher worked. But application firmware often remaps the console to a different UART and pins. The stock SDK’s uart_echo example uses UART1 on GPIO4 (TX) / GPIO3 (RX) at 115200, while another SDK device‑tree example keeps UART0 on 7/16 but at 2 Mbps. So if you keep your RX wire on GPIO16 after flashing and expect 115200 logs, you may read nothing. Practical approach: probe both candidates: - Try app log on GPIO4 TX at 115200 8N1. - If still blank, move back to GPIO16 TX and try 115200, then 2,000,000 8N1. (pine64.github.io) - BOOT strap and reset - You already removed 3.3 V from P8 (BOOT). Ensure it is not weakly pulled up elsewhere on the board. On BL602, BOOT must be LOW/floating at reset to boot from flash; if it’s HIGH the chip re‑enters ISP and your app won’t start (no AP, and depending on your terminal you may still see nothing). (pine64.github.io) - XTAL mismatch consequences - Your log shows eflash_loader_40m and a 40 MHz boot header. If your physical crystal is 26 MHz, the early clocking and RF init can fail so early that the UART console never comes up. The CLI supports explicit selection: for BL602 use --xtal 5 for 26 MHz. Reflashing with the correct xtal and a full erase eliminates this class of faults. Command below. (pypi.org) - Power integrity and cabling - The radio surge on AP bring‑up needs a decent 3.3 V rail. USB‑UART 3.3 V pins often sag; you correctly switched to an external supply. But the serial adapter must share ground with the module and PSU. Also, keep wires under ~10–15 cm for reliable 2 Mbps tests. Community reports also note underpowered dongles causing “works in flash, fails at AP”. (elektroda.com) - AP visibility and IP - On first boot with no Wi‑Fi creds, OpenBL602 creates a 2.4 GHz AP “OpenBL602_<MAC>”. Some builds use 192.168.169.1 for the management UI (instead of 192.168.4.1 typical on other chips). Scan with a phone and try both IPs if you can join. (github.com) - Recovery/safe mode - If there were stale settings in flash that suppress AP, power‑cycle five times quickly to enter OpenBeken Safe Mode, which forces AP with pin system disabled so you can recover. (github.com)
Practical guidelines (Ubuntu, step‑by‑step) 1) Wire for normal boot and logging - Remove any jumper from BOOT (P8). - External 3.3 V → VDD; GND of PSU, module and USB‑UART all tied. - For logs, connect USB‑UART RX to: - First try BL602 TX on GPIO4; 115200 8N1. - If no output, move RX to GPIO16; test 115200 then 2,000,000 8N1. (pine64.github.io) - Start a terminal: screen /dev/ttyUSB0 115200 or screen /dev/ttyUSB0 2000000 (Ctrl‑A K to quit). 2) Re‑flash with full erase and 26 MHz (if BL602L crystal is 26.000) - Put P8=HIGH and reset to enter ISP. - Run: bflb-mcu-tool --chipname bl602 --port /dev/ttyUSB0 --baudrate 115200 --erase --xtal 5 --firmware OpenBL602_1.18.187.bin - When it completes, remove P8 strap, power‑cycle, and retry logging/AP. (pypi.org) 3) Scan for AP - Use a phone or on Ubuntu: nmcli dev wifi rescan; nmcli -f SSID,SIGNAL dev wifi | grep -i openbl602 - If you connect, browse to 192.168.169.1 (primary for BL602) or 192.168.4.1 and provision Wi‑Fi. (github.com) 4) Force Safe Mode if needed - Five quick power cycles to force AP/safe mode, then clear any odd config from the web UI. (github.com)
Current information and trends - bflb‑mcu‑tool remains the maintained CLI (v1.10.0 uploaded Apr 27, 2025) and documents the BL602 --xtal codes: 1=24M, 2=32M, 3=38.4M, 4=40M (default), 5=26M. (pypi.org) - BL602 SDK examples commonly use UART1 on GPIO4/3 at 115200 for app demos, while some device‑tree configs keep UART0 at 7/16 with higher baud. Expect variance across firmwares; confirm by probing both. (pine64.github.io)
Supporting explanations and details - Why log pin changes after flashing: Once your firmware starts, it can remap UART functions to any GPIOs supported by the pinmux. SDK examples show multiple valid mappings; OpenBeken may follow similar conventions. That’s why flashing pins (7/16) and runtime log pins aren’t guaranteed to be identical. (pine64.github.io) - Why 26 MHz matters on BL602L: The eflash loader generates a boot header using the specified XTAL; wrong xtal disrupts PLL/system clocks very early, so UART output may never appear. The CLI exposes explicit XTAL selection for BL602 to avoid this. (pypi.org)
Practical checklist (quick triage) - Common ground between PSU, module, USB‑UART? If not, fix first. - BOOT (P8) floating/LOW at reset? Verify continuity. - Try log on GPIO4@115200, then GPIO16@115200, then GPIO16@2000000. - If still silent, re‑flash with --erase --xtal 5 (26 MHz). - Scan for “OpenBL602_XXXXXX” and try 192.168.169.1. (github.com)
Possible disclaimers or additional notes - If your device includes a BL0937/BL0942 energy metering front‑end and you later set those pins in OpenBeken, note that certain historical firmware combinations caused boot issues; Safe Mode recovery remains available. Not directly related to first‑boot AP, but good to know. (elektroda.com)
Brief summary - Your flash is good. Move your log RX wire off the flashing TX (GPIO16) and try the likely runtime console on GPIO4 at 115200; if still blank, try GPIO16 at 2,000,000 and 115200. Ensure BOOT is released and all grounds are common. If the crystal is 26 MHz (common on BL602L), re‑flash with --erase --xtal 5. Then scan for “OpenBL602_…”, and browse to 192.168.169.1 to configure Wi‑Fi. (pine64.github.io)
Questions for you - Can you share a clear photo of the module so we can read the crystal marking (e.g., “26.000” or “40.000”)? - When monitoring the boot, which BL602 TX pin did you actually connect to (GPIO16 or GPIO4)? At what baud rate? - Are the grounds of your PSU, module, and USB‑UART tied together during the serial test? - After re‑flash with --xtal 5 and BOOT released, does a phone see any SSID starting with OpenBL602_…? If you can connect, which of 192.168.169.1 or 192.168.4.1 opens the web UI?
You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
To flash the BL602 microcontroller using OpenBK on Ubuntu Linux with a USB-to-serial adapter, ensure the correct hardware setup and software tools. The BL602 requires GPIO8 (BOOT) to be pulled HIGH (3.3 V) during reset or power-up to enter flashing mode, contrary to some guides that suggest pulling BOOT to GND. The ROM bootloader communicates over UART0 with RX on GPIO7 and TX on GPIO16. OpenBeken provides precompiled BL602 firmware images, such as version 1.18.188, available for UART flashing and OTA updates. Recommended flashing tools on Linux include Bouffalo’s CLI tool "bflb-mcu-tool" (available on PyPI), the Rust-based "blflash," and the BLDevCube GUI. Using these configurations and tools ensures reliable UART flashing of the BL602. Summary generated by the language model.
