Flash Tools — BKFIL (bk_loader) Q&A

This page lists common issues encountered when flashing FGM842D firmware with BKFIL (bk_loader), quick diagnostics, and suggested fixes. If you still can't resolve the problem, collect the information listed at the end and escalate to the test lab.

Q1 — The flashing tool cannot find the COM port / "port not found"

A:

1. Check driver and cable

   • On Windows ensure CH340/CP210x drivers are installed. Reboot if driver was just installed.
   • Try a different USB cable or USB port. Prefer a data-capable cable (not power-only).

2. Verify device appears in OS

   • Windows: check Device Manager -> Ports (COM & LPT).
   • Linux: run dmesg | tail after plugging the cable to see ttyUSBx/ttyACMx assignment.

3. Permission issues (Linux)

   • Add your user to the dialout group or run sudo for bk_loader. Example: sudo ./bk_loader ... or sudo usermod -aG dialout $USER then re-login.

Q2 — Flash fails with "sync" / "failed to connect" / timeouts

A:

1. Check boot pin/auto-boot signals

   • BK loader often requires the target to be in bootloader mode. Confirm the development board auto-asserts RTS/DTR or has correct BOOT pins.

2. Try lower baud rate

   • Use a conservative baud (e.g., 115200 or 921600) if very high rates fail. Use command line -b option to set baud.

3. Ensure no other application is using the port

   • Close serial terminals (minicom/putty) before running bk_loader.

Q3 — Erase / write errors or "verify failed"

A:

1. Confirm firmware file and template

   • Verify the binary (MD5/SHA256) and ensure the all.bin/template matches the device map used by your board.

2. Use erase before download

   • Try bk_loader erase before download if residual data causes issues.

3. Check power stability

   • Ensure the DUT has a stable power source and is not brown‑outing during writes.

Q4 — "Permission denied" when running bk_loader on Windows or Linux

A:

1. On Windows: run the tool as Administrator.

2. On Linux: prefix command with sudo or fix device permissions (chmod/udev rules or add to dialout).

Q5 — Secure boot / key injection errors

A:

1. Verify key files and syntax

   • The writekey and --aes_key_path options require correct JSON/key files and paths. Use absolute paths to avoid confusion.

2. Check bk_loader version compatibility

   • Some key injection options are only supported in newer bk_loader releases. Use the tool version matching your vendor instructions.

3. Permissions and secureboot flags

   • On failure, check that file permissions allow bk_loader to read keys, and that secureboot flags are set as required.

Q6 — The board reboots immediately after flashing or boots into wrong mode

A:

1. Check partition/template configuration

   • Incorrect partition table or all.bin offsets may overwrite bootloader or config areas.

2. Verify boot mode pins

   • Ensure pins that select normal boot vs download are in the normal position after flashing.

Q7 — CLI gives cryptic JSON / config errors

A:

1. Validate JSON files

   • If using custom read/erase JSON, validate JSON syntax (e.g., jq . config.json).

2. Use sample configs

   • Start with vendor-provided example JSON files to ensure correct keys and structure.

Q8 — Long flash times or stalls during download

A:

1. Check baud and flow control

   • High baud with unstable USB or poor cable can stall. Try lower baud and enable hardware flow control if supported.

2. Try different host machine / USB controller

   • USB controllers differ; try another PC or a powered USB hub.

What to collect when escalating

• OS and version (Windows/Linux/macOS)
• bk_loader / BKFIL version and exact command line used
• Full console output (capture stdout/stderr) — run with verbose flags if available
• dmesg / Device Manager screenshot showing COM assignment
• Firmware file name and checksum (MD5/SHA256)
• Board revision and schematic snapshot of the boot pins
• Power supply details (voltage, current limit)