Product studyGraphLab Boot / Pro

RPMsg system-health monitoring

A shared display path needs a clear contract between Linux and the real-time firmware. This study explores a small, versioned RPMsg protocol for heartbeats, system states, warnings, and acknowledgements, with project-defined reactions on the real-time side.

Service HMI in an industrial cabinet showing a heartbeat trace and equipment-health tiles with one amber attention state.

Intended outcome

Turn cross-core health into explicit, testable states

Linux would publish a monotonic heartbeat and a bounded set of system states. The real-time firmware would validate protocol version, sequence, timing, and payload before changing the visible state.

Timeouts and invalid messages would map to defined reactions such as retaining the current frame, showing a warning, selecting a fallback screen, or requesting recovery. Each reaction would be chosen for the target product rather than assumed by the transport.

Proposed behavior

A project-defined operating sequence

Session negotiation
Both sides establish compatible protocol versions, capabilities, and a fresh session identifier.
Health exchange
Linux sends sequence-numbered heartbeats and state changes while the real-time side validates freshness.
Policy reaction
Accepted messages update approved status content; timeouts or invalid states invoke the configured fallback policy.
Recovery
A new Linux session is qualified before its state or rendered frame can become authoritative again.

Architecture

Responsibilities stay explicit

Transport

RPMsg provides the cross-core message channel, endpoint lifecycle, and payload delivery for the selected BSP integration.

Protocol

A separate application contract defines message headers, versions, session identity, sequence, states, validity, and acknowledgements.

Reaction policy

GraphLab Core maps valid messages and protocol failures to visible states and any permitted recovery request.

Project inputs

Integration points to define and validate

Remote processor and RPMsg lifecycle in boot, shutdown, crash, and restart paths.
Protocol versioning, endianness, size limits, session identity, and sequence handling.
Heartbeat source, interval, timeout, startup grace period, and clock assumptions.
Allowed states, warning text, acknowledgements, and rate limiting.
Memory, cache, endpoint, and resource-table configuration for the target BSP.
Fault injection for loss, delay, duplication, corruption, restart, and incompatible versions.

Assess the concept