I can't create this file.

[michkovitalik]

I can't create this file.

[michkovitalik]

option_bytes48.bin?

[DavidClawson]

Hey @michkovitalik —

option_bytes48.bin gets generated partway through a successful make build, so if it's not showing up in firmware/build/ it means the build is failing before it gets to that step (or hasn't been run yet).

Could you narrow it down by posting the output of these commands?

cd firmware                                                                                                                               
ls at32f403a_lib FreeRTOS            # confirm the two external libs are cloned
arm-none-eabi-gcc --version          # confirm the toolchain is installed
make 2>&1 | tail -40                 # the last bit of the build output

The most common causes I'd expect:

1. Missing external libraries — at32f403a_lib/ and FreeRTOS/ need to be cloned into firmware/ first:
   cd firmware
git clone https://github.com/ArteryTek/AT32F403A_407_Firmware_Library.git at32f403a_lib
git clone https://github.com/FreeRTOS/FreeRTOS-Kernel.git FreeRTOS
2. Toolchain not installed — on Linux:
   sudo apt install gcc-arm-none-eabi libnewlib-arm-none-eabi dfu-util make
3. make wasn't run in the firmware/ directory — the Makefile lives there, not at the repo root.

[michkovitalik]

teminal.tar.gz

[michkovitalik]

All the above conditions are met.

[DavidClawson]

Hey @michkovitalik — found it, and it's a bug on my end. Your build log actually shows a successful build (Built: build/firmware.bin (210132 bytes), only harmless linker warnings). The problem is that my README, DFU guide, and first-time-setup instructions all promised option_bytes48.bin would appear in build/ after make, but there was no Makefile rule to actually generate it. You were chasing a file that didn't exist. Sorry for the runaround.

Just pushed a fix — the Makefile now generates build/option_bytes48.bin as part of the normal make target. Pull latest, rebuild, and you should see it:

cd firmware
git pull
make
ls -l build/option_bytes48.bin   # should be 48 bytes

Then, for the first-time option-byte flash, you need to be in ROM DFU mode, not the HID bootloader mode — these are two different things on this device:

• HID bootloader mode (the "BOOTLOADER MODE" LCD screen, entered from Settings → Firmware Update) → only used by make flash for normal updates. Cannot write option bytes.
• ROM DFU mode (LCD stays dark, entered via the BOOT0 jumper + pinhole reset — same jump from Test point Boot0 #1) → required for the EOPB0 one-shot. Enumerates as 2e3c:df11.

So the full first-time flow, in order:

# 1. Build (generates firmware.bin, bootloader.bin, option_bytes48.bin)
cd firmware
make

# 2. Enter ROM DFU: BOOT0 jumper to 3V3, pinhole reset. Verify:
dfu-util -l     # should show 2e3c:df11 with alt=0 and alt=1

# 3. Set EOPB0 = 0xFE (one-time, enables 224KB SRAM)
dfu-util -a 1 -d 2e3c:df11 -s 0x1FFFF800 -D build/option_bytes48.bin

# 4. Pinhole reset (still in DFU), then flash bootloader + app
make flash-all

# 5. Remove BOOT0 jumper, pinhole reset — device boots normally.
# From now on, all updates go over USB-C via `make flash`.

One small warning you'll see and can ignore: Invalid DFU suffix signature and Error sending dfu abort request — both cosmetic, they don't affect the write. The line you want to see is Download done. / File downloaded successfully.

Thanks for the terminal logs — they made this easy to diagnose, and the fix now benefits every future Linux user. Let me know how step 3 onward goes.

[michkovitalik]

dfu.bmp

[michkovitalik]

windows11 ok

dfu.bmp

[michkovitalik]

[michkovitalik]

[michkovitalik]

windows11 ?

[michkovitalik]

I solved it with a program artery isp programmer

[michkovitalik]

[DavidClawson]

Hey @michkovitalik — this is incredibly helpful, thank you. I've been writing the Windows flashing docs essentially blind because I only have a Mac to test on, and your screenshot is the first time I've actually seen the Artery ISP Programmer interface. The two things you circled (EOPB0(SRAM) → 224KB SRAM, then Apply to device) are exactly the workflow I needed to document — it's dramatically simpler than the Linux dfu-util command for a first-timer.

Would you be willing to let me include this screenshot in the project documentation, with credit to you? It would go into docs/dfu_mode_guide.md as a proper Windows walkthrough section, and it would save every future Windows user a lot of confusion. Happy to link back to your GitHub profile as the contributor.

If you're up for it, two quick follow-up questions to round out the walkthrough:

1. After you set the option byte, how did you program the actual firmware? Did you use the same Artery ISP Programmer for that step too — writing bootloader.bin to 0x08000000 and firmware.bin to 0x08004000 via the Flash programming tab? Or did you use a different tool?

2. How did you get the device into ROM DFU mode on your unit — the BOOT0 jumper + pinhole reset from the DFU guide, or a different method? Any photos of your hardware setup are extremely welcome but absolutely not required.

Either way, thank you for sticking with this all the way through. You've essentially written the Windows first-flash documentation for us by doing — and as of tomorrow this project is officially open to community contributions, with a new CONTRIBUTING.md that specifically calls out "documentation you've verified" as one of the most valuable things anyone can contribute.