ethanjli
commented
3 years ago It looks like the problem is that when the firmware's event log is reset, the backend needs to start requesting all log events starting from id 0; otherwise (and this is what I see happening now) the backend ignores log events from the firmware until the next one matches the expected log ID. When it does a reset of expectedLogEvent, the backend should also reset its ID mappings for active log events, as well as its clock synchronizer.
Currently the firmware discards all elements with id less than expectedLogEvent. Obviously it shouldn't do this if it has just started up, because this means it's discarding all of its elements upon restart. This is probably why what I had implemented previously was not enough to address the issue.
The most robust way to determine whether expectedLogEvent is a stale request for log events is by attaching a session ID (randomly-generated uint32_t, to make it unique) to each ExpectedLogEvent and NextLogEvents; this way both the sender and receiver know when a sender reset occurs. This is what I've done in 3020808. This breaks the original spirit of having all state synchronization in the Pufferfish software be sessionless (i.e. a "stateless connection"); however, memory constraints on the MCU mean that we do have to discard old log events, so we do need to have a session for now. In the future, once we have persistent storage on FRAM, we could instead save and load the event log ID counter to/from there; then we wouldn't actually need to have a a session ID. But that's a while away.
When the backend application is running, and the firmware is unplugged and plugged back in, some events seem to be overwritten, and then the backend's mapping of active event IDs from the firmware to the backend's numbering systems becomes incorrect (e.g. a "Ventilation Started" event shows up in the frontend as an active alarm). I had already implemented something to deal with this, but I guess it isn't working correctly.