let's not do that for now..
All checks were successful
EIVE/eive-obsw/pipeline/pr-main This commit looks good

This commit is contained in:
Robin Müller 2024-06-05 12:47:17 +02:00
parent 1f8dc67922
commit 5dd0c2a5cb
Signed by: muellerr
GPG Key ID: A649FB78196E3849
2 changed files with 16 additions and 3 deletions

View File

@ -16,6 +16,15 @@ will consitute of a breaking change warranting a new major release:
# [unreleased]
# [v8.1.1] 2024-06-05
## Added
- PLOC SUPV MPSoC update re-try logic for the `WRITE_MEMORY` command. These packets form > 98%
of all packets required for a software update, but the update mechanism is not tolerant against
occasional glitches on the RS485 communication to the PLOC SUPV. A simple re-try mechanism which
tries to re-attempt packet handling up to three times for those packets is introduced.
# [v8.1.0] 2024-05-29
## Fixed

View File

@ -465,7 +465,10 @@ ReturnValue_t PlocSupvUartManager::writeMemoryHandlingWithRetryLogic(supv::Write
}
triggerEvent(WRITE_MEMORY_FAILED, buildProgParams1(progPercent, update.sequenceCount),
update.bytesWritten);
// Clear data structures related to reply handling.
serial::flushTxRxBuf(serialPort);
recRingBuf.clear();
decodedRingBuf.clear();
}
return result;
}
@ -577,10 +580,11 @@ ReturnValue_t PlocSupvUartManager::handlePacketTransmissionNoReply(
ReturnValue_t status = handleUartReception();
if (status != returnvalue::OK) {
result = status;
// We probably missed a packet or the communication was temporarily corrupted..
// It probably would be good to bail immediately for re-try logic.
if (result == HDLC_ERROR) {
return result;
// We could bail here immediately.. but I prefer to wait for the timeout, because we should
// ensure that all packets which might be related to the transfer are still received and
// cleared from all data structures related to reply handling.
// return result;
}
}
if (not decodedQueue.empty()) {