sid/renode-m68hc12
1
0
Fork 0
Code Issues 6 Pull requests 1 Projects Releases Packages Wiki Activity Actions

BGND is a no-op, not real background-debug-mode entry #4

New issue
Open
opened 2026-08-24 11:43:17 +02:00 by sid · 0 comments
sid commented 2026-08-24 11:43:17 +02:00
Owner
Copy link

Summary

BGND (opcode 00) is decoded but executes as a break-style no-op
(M68HC12.cs:361-363), so it does nothing at all:

case "NOP":
case "BGND":
    break;

On real silicon, BGND is the entry point into Background Debug Mode
(BDM): the CPU stops executing and waits for serial debug commands on the
BKGD pin (or, in emulation, for a debugger to resume it). It is the hardware
breakpoint/embedded-debug feature of the 68HC12 family.

Impact

  • Programs that use BGND as a software breakpoint (common in firmware debug
    builds and monitor/ROM code) keep running instead of halting.
  • The BKGD/BDM debug channel is absent, so no BDM protocol support exists.

Current behavior

  • BGND falls through the same case as NOP: PC advances, nothing else.
  • ExecuteInstructions has no halt reason for a BGND stop; the Renode monitor
    cannot distinguish "hit BGND" from normal execution.

Affected files

  • src/Infrastructure/src/Emulator/Peripherals/Peripherals/CPU/M68HC12/M68HC12.cs
  • Possibly the ExecutionResult handling in ExecuteInstructions
    (M68HC12.cs:49-70)

Desired behavior

BGND halts execution and surfaces as a distinct stop reason so that:

  • The Renode monitor reports the CPU halted on BGND at a given PC.
  • A debugger (e.g. GDB via the existing ICpuSupportingGdb plumbing) can
    resume execution from the BGND instruction.
  • The halt/continue semantics match how other Renode CPUs expose
    breakpoint-style stops (look at the MSP430X or ARM interpreter CPUs for the
    established pattern).

Acceptance criteria

  • Executing BGND stops the machine and is distinguishable from a normal
    stop and from WAI/STOP.
  • The CPU can be continued and resumes at the instruction after BGND.
  • A unit/Robot test demonstrates the halt and resume round-trip.
  • NOP keeps its existing behavior.

Suggested approach

  • Add a bgndHalted (or reuse a Breakpoint/DebugRequested halt flag)
    state checked in the ExecuteInstructions loop, similar to
    waitingForInterrupt (M68HC12.cs:61-63).
  • Wire it to the monitor's pause/halt-reason reporting so mach shows the
    stop reason.
  • Full BDM command-set emulation (reads/writes over BKGD) is a much larger
    effort; a minimal first step is halt-on-BGND + resume, with BDM protocol as
    a documented follow-up.
## Summary `BGND` (opcode `00`) is decoded but executes as a `break`-style no-op (`M68HC12.cs:361-363`), so it does nothing at all: ```csharp case "NOP": case "BGND": break; ``` On real silicon, `BGND` is the entry point into **Background Debug Mode (BDM)**: the CPU stops executing and waits for serial debug commands on the `BKGD` pin (or, in emulation, for a debugger to resume it). It is the hardware breakpoint/embedded-debug feature of the 68HC12 family. ## Impact - Programs that use `BGND` as a software breakpoint (common in firmware debug builds and monitor/ROM code) keep running instead of halting. - The `BKGD`/BDM debug channel is absent, so no BDM protocol support exists. ## Current behavior - `BGND` falls through the same case as `NOP`: PC advances, nothing else. - `ExecuteInstructions` has no halt reason for a BGND stop; the Renode monitor cannot distinguish "hit BGND" from normal execution. ## Affected files - `src/Infrastructure/src/Emulator/Peripherals/Peripherals/CPU/M68HC12/M68HC12.cs` - Possibly the `ExecutionResult` handling in `ExecuteInstructions` (`M68HC12.cs:49-70`) ## Desired behavior `BGND` halts execution and surfaces as a distinct stop reason so that: - The Renode monitor reports the CPU halted on `BGND` at a given PC. - A debugger (e.g. GDB via the existing `ICpuSupportingGdb` plumbing) can resume execution from the `BGND` instruction. - The halt/continue semantics match how other Renode CPUs expose breakpoint-style stops (look at the MSP430X or ARM interpreter CPUs for the established pattern). ## Acceptance criteria - Executing `BGND` stops the machine and is distinguishable from a normal stop and from `WAI`/`STOP`. - The CPU can be continued and resumes at the instruction after `BGND`. - A unit/Robot test demonstrates the halt and resume round-trip. - `NOP` keeps its existing behavior. ## Suggested approach - Add a `bgndHalted` (or reuse a `Breakpoint`/`DebugRequested` halt flag) state checked in the `ExecuteInstructions` loop, similar to `waitingForInterrupt` (`M68HC12.cs:61-63`). - Wire it to the monitor's `pause`/halt-reason reporting so `mach` shows the stop reason. - Full BDM command-set emulation (reads/writes over `BKGD`) is a much larger effort; a minimal first step is halt-on-BGND + resume, with BDM protocol as a documented follow-up.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
upstream
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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/renode-m68hc12#4
No description provided.