Repository navigation
Map simulated MEM-AP devices and shared RAM. - #83
Conversation
MEM-AP fixtures held only ordinary bytes, so register side effects and device bus errors could not run through the simulated DAP stack. Map fixed address ranges to complete device accesses while keeping byte order, posting and TAR state in the MEM-AP. Bus errors set sticky DP state after acceptance; fixture helpers reject mapped ranges so they cannot bypass device effects. Wrap callback failures so a callback WAIT cannot replay an accepted access. Preserve the diagnostic text and context cancellation or deadline identity.
Independent MEM-AP byte fixtures could not expose one memory store through several APs. Add sparse shared RAM with explicit fixture writes and detached snapshots, preserving each AP's byte order and keeping private device windows separate. The zero RAM value is usable. Bus accesses validate width, alignment, bounds and cancellation before effects; fixture operations copy their slices and remain separate from bus traffic.
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: da230411d8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review Please review head |
|
Codex Review: Didn't find any major issues. Chef's kiss. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
MEM-AP simulations can now route bounded address ranges to devices and share RAM across APs. After adding both MEM-AP fixtures, map one store through them before connecting the wire:
Here
dapsimisdap/sim. SeparateMemoryDevicevalues can occupy the same register address through different APs. TheirRead(ctx, addr, data)andWrite(ctx, addr, data)methods receive one complete access in address byte order; the MEM-AP keeps numeric byte order, DRW lanes, posting and TAR state. Compose the target with the existingswd/simwire and acquire MEM-APs through the public DAP API. Release MEM-APs before the DP, retaining owners if cleanup fails. All traffic and shared-store access must be serialized.Existing ordinary-memory fixture calls remain usable:
For a mapped RAM range, use
ram.SetBytes(addr, data)andram.Bytes(addr, len(data))instead. Target fixture helpers reject mapped ranges so they cannot bypass device effects. Live reads and writes still go throughdap.MemAP.Why
The simulator previously stored ordinary bytes behind each MEM-AP. Register side effects required separate memory fakes, and AP views could not share one RAM store. Device callbacks now run beneath the real SWD and DAP layers. Mapping crossings and
ErrBusFaultset STICKYERR after AP acceptance; subsequent requests observe FAULT. Other callback errors reportErrDeviceFailure;errors.Is(err, dapsim.ErrDeviceFailure)distinguishes them from bus faults. Their text and context cancellation/deadline identity survive, but their protocol classifications do not, so a callback WAIT cannot replay an accepted write. Mappings freeze before traffic, narrow writes do not synthesize read/modify/write, and no failed access is replayed.The simulator does not execute processors or model bus latency or pending completion.
Documentation
The DAP guide describes mapping, shared-store setup and snapshots, fault behavior, serialization and cleanup. Architecture and capability documentation reflect the implemented scope.