Skip to content
Process Docs
Extracting Blackbox Logs Over USB Mass Storage

Extracting Blackbox Logs Over USB Mass Storage

The G473 V2 stores blackbox data on 16 MB of onboard SPI flash. Rather than streaming it over MSP, the board can reboot into USB mass-storage mode and expose that flash as an ordinary block device.

Procedure

Check what’s on the flash

In the CLI:

flash_info
Flash sectors=256, sectorSize=65536, pagesPerSector=256, pageSize=256,
totalSize=16777216 JEDEC ID=0x00852018
Partitions:
  0: FLASHFS   0 255
FlashFS size=16777216, usedSize=2306048

usedSize versus totalSize tells you how much is waiting. If they are equal, the flash is full — see the warning below.

Reboot into mass-storage mode 

msc

The board reboots immediately and disconnects. It will no longer answer CLI or MSP while in this mode.

Find the block device 

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

It appears as a small disk with a single partition — typically /dev/sdb1, labelled BETAFLT. Confirm the label rather than trusting the letter:

udisksctl status | grep -i betaflt

Mount it 

udisksctl mount -b /dev/sdb1
Mounted /dev/sdb1 at /run/media/hans/BETAFLT
udisksctl sometimes reports Error looking up object for device /dev/sdb1 on the first attempt, immediately after the device appears. This is a udisks indexing lag, not a failure — wait a second or two and run it again.

Copy the logs you want

    • btfl_001.bbl
    • btfl_002.bbl
    • btfl_006.bbl
    • btfl_all.bbl
    • padding.txt
cp /run/media/hans/BETAFLT/btfl_00*.bbl ~/logs/

Take the numbered btfl_NNN.bbl files only. btfl_all.bbl is just those same logs concatenated, and padding.txt is filler occupying the unwritten remainder of the chip — copying it wastes a great deal of time for nothing.

Unmount and return to normal mode 

udisksctl unmount -b /dev/sdb1

Then physically unplug and replug the board. Mass-storage mode persists across a soft reboot; only a real power cycle brings the flight firmware back.

The flash does not wrap

Betaflight’s blackbox stops logging when the flash is full. It does not overwrite the oldest data. Once usedSize equals totalSize, every subsequent arm records nothing at all — silently.

So erasing is a routine part of the cycle, not cleanup:

flash_erase
Erasing, please wait ...

Done.

Verify with flash_info that usedSize=0 before flying again. Copy anything you want to keep first — the erase is immediate and unrecoverable.

Next

Decode the log into something you can analyse.

Last updated on
Decoding a Blackbox Log