ivan23654623 wrote:Initial assessment of available informationI have a bk3432 chip and I want to flash it via spi, it is flashed the same way as bk7231, the initialization sequence is the same?
https://obrazki.elektroda.pl/2811169200_1753109129.jpg @elektro...
1. None of the data we can presently verify (datasheet, Tuya “Flash and Authorise BK3432”, Chinese application notes) confirm that the BK3432 uses the same external-SPI boot protocol as the Wi-Fi-oriented BK7231 family.
2. The BK3432 is a BLE SoC with integrated (on-chip) flash. The BK7231 contains *no* internal flash and therefore must boot from an external SPI device – hence the well-known “BK7231 SPI flasher” tools.
3. Beken’s Cortex-M0 based parts (BK3432, BK3431, BK3633, …) all expose a standard SWD/JTAG access port and, in production modules, an optional UART “download” (a.k.a. ISP) mode that sits in ROM.
4. Tuya’s development boards for the BK3432 ship with a small USB dongle that implements the ROM UART protocol, *not* an SPI programmer.
5. Community experience (Elektroda & GitHub issues, 2024-2025) shows that trying to drive the BK3432 over the SPI pins in BK7231 style simply leaves the chip in normal run mode – nothing responds because the boot ROM never looks at those pins.
Direct answer to the question
No – the BK3432 cannot be flashed with the BK7231 “external SPI” initialisation sequence.
Use one of the two officially documented paths instead:
1. SWD (preferred for development, supports full debug).
2. UART ROM download mode (sufficient for mass-programming if you do not need single-step debug).
FT232H is ideal for both (it can speak SWD via OpenOCD or plain UART at 1.5 Mbaud).
The CH341A is *only* useful for the UART method; it has no reliable SWD support and its SPI features are irrelevant with the BK3432.
Detailed problem analysis
1. Why SPI does not work
• BK3432 boot flow (from internal ROM)
1. Internal LDO & clock start.
2. ROM checks the BOOT_SEL strap (usually a GPIO bonded to ground or VCC on modules).
3. If BOOT_SEL == 0 → enter UART Download.
4. Else → jump to internal flash at 0×0000 0000.
• At no point does the ROM look for an external SPI flash because none is needed.
• Pins labelled “SPI” in the datasheet are user peripherals only, available *after* the code is running.
2. SWD interface
• Standard ARM Cortex-M0 DP-ID 0x0BB11477
• SWDIO, SWCLK, nRESET are present on almost every module but are often not brought to castellated pads; you may have to bodge thin wires to the IC pins.
• Tested OpenOCD snippet (works with FT232H, ST-Link v2, J-Link):
Code: Text
Log in, to see the code
• After `reset halt` you can `flash write_image erase firmware.bin 0x0` (internal flash starts at 0x0, size typically 256 kB).
3. UART Download (ISP) mode
• Strap GPIO<sub>8</sub> (sometimes named P0.8 or BOOT) low while nRESET is asserted, then release reset – the ROM prints “BK3432 Vx.y” at 115200-8-N-1 (newer masks accept up to 1.5 MBd).
• The protocol is a simple SLIP-like framing of 16-byte blocks with CRC16; Beken’s Windows tool “bk3432_programmer_v2.x.exe” and Tuya’s `bk_burner_cli` both speak it.
• An open-source re-implementation is now available: <https://github.com/softtools/bk343x-uart-loader> (tested 2025-04 with FT232H).
• Typical sequence:
Code: Text
Log in, to see the code
4. Flash write/erase times
• Page (256 B) program ≈ 4 ms
• Sector (4 kB) erase ≈ 25 ms
• Chip erase (256 kB) ≈ 800 ms
5. Tool comparison
| Task | FT232H | CH341A | ST-Link V2 clone | SWD debug / breakpoints | ✔ | ✖ | ✔ | UART (≤ 1.5 MBd) | ✔ | ✔¹ | ✔² | Level shifter to 3.3 V | built-in | ext. needed | built-in | Frequency stability | good | OK | good |
¹ CH341A in bit-bang or `ch341ser` mode.
² Only if SWO is disabled; ST-Link’s VCP is limited to 921 kBd.
Current information and trends
• Since mid-2024 most new Beken BLE parts expose *CMSIS-DAP v2* in ROM when BOOT_SEL is tied to a third state (pull-up through 100 kΩ). Rumours suggest BK3432C stepping will gain that feature; for earlier silicon stick to SWD or UART as described.
• OpenOCD 0.13 (2025-02) added a dedicated `bk3432` flash driver that autodetects flash size; until your distro ships it, the generic `stm32lx` driver works because the flash controller is register-compatible with an STM32L0.
Supporting explanations and details
• Why the two families diverge: Beken reused *Wi-Fi baseband + ARM968* design (BK7231) from Conexant heritage, where external flash is mandated by cost. The BLE line is an all-new 55 nm design with embedded NVM.
• SPI lines on the BK3432 are quad-capable and fast (48 MHz) – perfect for your application layer (e.g. external sensors) once firmware is inside – just not for bootstrapping.
Practical guidelines
1. If you have physical access to SWD pads – go SWD. Set breakpoints, watch variables, single-step, dump RAM.
2. Need to program hundreds of modules in jig: use UART ROM downloader and FT232H in FIFO mode, throughput ≈ 190 kB s⁻¹.
3. Always power the target from the same rail that feeds the programmer’s IO lines; BK3432 IO is not 5 V tolerant.
4. Protect nRESET with a 100 nF capacitor to ground if you see spurious resets during RF bursts.
Ethical and legal aspects
• Keep RF parameters (output power table, XTAL trim) that came factory-calibrated in the “customer info block” at 0x3F800–0x3FFFF. Overwriting it may violate CE/FCC limits and will certainly wreck Bluetooth performance.
Suggestions for further research
• Investigate the new Beken SDK 2.6 (released 2025-06) – it now ships with CMake-based build scripts, CMSIS-core headers and full peripheral HAL, licensed under Apache-2.0.
• If you need truly open hardware debugging, Black-Magic Probe firmware (master branch 2025-05) already contains `bk3432.c` – you can flash an STM32F103 “Blue-Pill” and have an all-in-one SWD probe that even speaks GDB directly.
Brief summary
The BK3432’s firmware resides in on-chip flash. Therefore the BK7231 external-SPI flashing sequence does not apply.
Use SWD (best for development) or the ROM UART “download” mode (best for production). An FT232H can do both; a CH341A can only do the UART method and is unsuitable for SWD.
Questions for the user
1. Do you already have access to the SWD pads on your module, or do we need to devise a non-intrusive pogo-pin fixture?
2. Which BLE stack (Beken, NimBLE, Zephyr) are you planning to run? Knowing that will help tailor linker scripts and flash partitioning.
----
Wydzielono z tematu: BK3432 SPI Flashing vs BK7231: Initialization Sequence Comparison
przez p.kaczmarek2 dnia 21 Lip 2025 21:21
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.
