Add in-circuit flash programming (BDM flash programmer / S19 loader) #5

New issue

Open

opened 2026-09-24 09:53:59 +02:00 by sid · 0 comments

sid commented

2026-09-24 09:53:59 +02:00

Owner

Current state

m68hc11-elf-objcopy produces srec/symbolsrec/binary (verified: objdump -i lists these formats).
No flash loader, no BDM protocol support, no flash programmer binary.

Motivation

Building a hex file is only half the workflow; engineers need to flash the part. A GNU-based replacement should offer at least:
- robust S-record generation/validation (checksums, address ranges), and
- an in-circuit programmer path for common probes (P&E, USBDM/TBDML) or a documented bootloader serial protocol.

Proposed scope

Hardening and wrappers around objcopy for S19/S28/S37 output (address range selection, checksum verification, fill for gaps).
A flash-programming tool supporting one or more in-circuit backends:
- BDM via P&E Multilink/TBDML/USBDM (probe protocol), and/or
- a serial bootloader protocol for supported parts.
Device-specific flash parameters (sector size, timing, command sequence) drawn from the device support pack (see issue #03).

Acceptance criteria

A .elf from a -m9s12x build converts to a validated S-record with correct addresses and checksums.
A reference device can be erased/blank-checked/programmed/verified end-to-end through at least one in-circuit backend.
Flash programming is exercised in CI on the simulator (a mock flash programming session against gdb-sim), with hardware path documented.

References

pkgs/m68hc11-toolchain-tarball.nix (packaging)
tests/tarball-smoke.sh
flake.nix checks

CodeWarrior ships flash programming through the debugger probe (BDM) and a standalone flash programmer. This repo's toolchain stops at ELF/S-record output. There is no way to program a physical device's flash from a command-line tool. ## Current state - `m68hc11-elf-objcopy` produces `srec`/`symbolsrec`/`binary` (verified: `objdump -i` lists these formats). - No flash loader, no BDM protocol support, no flash programmer binary. ## Motivation - Building a hex file is only half the workflow; engineers need to flash the part. A GNU-based replacement should offer at least: - robust S-record generation/validation (checksums, address ranges), and - an in-circuit programmer path for common probes (P&E, USBDM/TBDML) or a documented bootloader serial protocol. ## Proposed scope - Hardening and wrappers around `objcopy` for S19/S28/S37 output (address range selection, checksum verification, fill for gaps). - A flash-programming tool supporting one or more in-circuit backends: - BDM via P&E Multilink/TBDML/USBDM (probe protocol), and/or - a serial bootloader protocol for supported parts. - Device-specific flash parameters (sector size, timing, command sequence) drawn from the device support pack (see issue #03). ## Acceptance criteria - A `.elf` from a `-m9s12x` build converts to a validated S-record with correct addresses and checksums. - A reference device can be erased/blank-checked/programmed/verified end-to-end through at least one in-circuit backend. - Flash programming is exercised in CI on the simulator (a mock flash programming session against `gdb-sim`), with hardware path documented. ## References - `pkgs/m68hc11-toolchain-tarball.nix` (packaging) - `tests/tarball-smoke.sh` - `flake.nix` checks

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sid/m68hc11-toolchain#5

No description provided.

Rows
Columns