Uniformization of behaviour of the eUpdater
of amc
, ems
, mc4plus
and mc2plus
#490
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR makes sure that the
eUpdater
of the all the ETH boards behaves in the same way, so that theFirmwareUpdater
receives the same replies from all ETH boards.More details
If the
FirmwareUpdater
sends commands withopc = uprot_OPC_PROG_DATA
with a chunk of data with address that does not belong to the valid FLASH of the receiving board, now all boards behave in the following way:uprot_RES_OK
to tell that the board has successfully managed the command despite the fact that the data to program was not valid.This behavior is needed because, so far,
FirmwareUpdater
reads the .hex files and sends commands for every chunk of data the file contains, even if that memory does not belong to FLASH.So, we need a protection in the board vs wrong memory programming (and that was already implemented) but we also need that the board sends back a
uprot_RES_OK
toFirmwareUpdater
so that this latter can print / return a OK result.This PR makes sure that
amc
,ems
,mc4plus
andmc2plus
do that.Tests
I have tested the new code on an
ems
and anamc
board andFirmwareUpdater
succeeds in programming the boards.It however prints a KO result because of an incorrect count of the number of sent commands.
Behavior of
FirmwareUpdater
for versions ofeUpdater
v2.23
The binary of
eUpdater
, versionv2.23
, has worked fine in updating its FLASH, so we don't need to operate any retrofit.Cleaning up
The changes for the above are just the five .c files. However, I noticed that there are a lot of un-necessary .hex binaries in the
env
folders ofems
,mc4plus
andmc2plus
so I have removed themFurther PRs
Binaries in
icub-firmware-build
As per title. The PR will soon come.
Changes to
FirmwareUpdater
As previously written, the boards legacy and new binaries of
eUpdater
are robust vs wronguprot_OPC_PROG_DATA
commands, butFirmwareUpdater
prints a KO result despite the programming of the FLASH is successful.To solve the KO result in
FirmwareUpdater
we need to:++progdata.mNProgSteps;
removed in FirmwareUpdater - fix programming ETH board result and message icub-main#944;FirmwareUpdater
so that it discards the commands that ask to program non-FLASH data.