eive/eive-obsw
eive/eive-obsw
12
3
Fork 0
Code Issues 4 Pull Requests 2 Releases 119 Wiki Activity

This bugfix might be super important #621

Merged
muellerr merged 6 commits from possible_bugfix_dual_lane_assy into main 2023-04-28 15:35:55 +02:00
Conversation 0 Commits 6 Files Changed 2 +16 -1
2 changed files with 16 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
CHANGELOG.md
View File

@ -16,6 +16,10 @@ will consitute of a breaking change warranting a new major release:
# [unreleased]
# [v2.2.0] to be released
# [v2.1.0] to be released
## Changed
- Adapt EM configuration to include all GomSpace PCDU devices except the ACU. For the ACU
@ -34,6 +38,16 @@ will consitute of a breaking change warranting a new major release:
- Host build is working again. Added reduced live TM helper which schedules the PUS and CFDP
funnel.
# [v2.0.5] to be released
- The dual lane assembly transition failed handler started new transitions towards the current mode
instead of the target mode. This means that if the dual lane assembly never reached the initial
submode (e.g. mode normal and submode dual side), it will transition back to the current mode,
which miht be `MODE_OFF`. Furthermore, this can lead to invalid internal states, so the subsequent
recovery handling becomes stuck in the custom recovery sequence when swichting power back on.
- The dual lane custom recovery handling was adapted to always perform proper power switch handling
irrespective of current or target modes.
# [v2.0.4] 2023-04-19
## Fixed

3
mission/system/acs/DualLaneAssemblyBase.cpp
View File

@ -205,7 +205,8 @@ bool DualLaneAssemblyBase::checkAndHandleRecovery() {
opCode = pwrStateMachine.fsm();
if (opCode == OpCodes::TO_OFF_DONE or opCode == OpCodes::TIMEOUT_OCCURED) {
customRecoveryStates = RecoveryCustomStates::POWER_SWITCHING_ON;
pwrStateMachine.start(targetMode, targetSubmode);
// Command power back on in any case.
pwrStateMachine.start(HasModesIF::MODE_ON, targetSubmode);
gaisser marked this conversation as resolved
gaisser commented 2023-04-28 14:56:16 +02:00
Review
Copy Link

Is this working in combination with the call to opCode = pwrStateMachine.fsm(); directly afterwards (line 213)? (I haven't checked the fsm() call, so this might be perfectly fine.)

In line 215 (

mission/system/acs/DualLaneAssemblyBase.cpp Line 215 in b10275ca43
customRecoveryStates = RecoveryCustomStates::DONE;
) customRecoveryState will be set to RecoveryCustomStates::DONE; if we entered the "if" in line 206 with OpCodes::TIMEOUT_OCCURED, is this expected?

Is this working in combination with the call to ``opCode = pwrStateMachine.fsm();`` directly afterwards (line 213)? (I haven't checked the fsm() call, so this might be perfectly fine.) In line 215 (https://egit.irs.uni-stuttgart.de/eive/eive-obsw/src/commit/b10275ca43f13ee68be013c7ece3b63acf762130/mission/system/acs/DualLaneAssemblyBase.cpp#L215) ``customRecoveryState`` will be set to `` RecoveryCustomStates::DONE;`` if we entered the "if" in line 206 with ``OpCodes::TIMEOUT_OCCURED``, is this expected?
muellerr commented 2023-04-28 15:07:25 +02:00
Review
Copy Link

Why shouldn't it work? This mechanism has always worked properly when targetMode is correct. The immediate fsm call will send the swtich commands, the replies take some time.

Why shouldn't it work? This mechanism has always worked properly when `targetMode` is correct. The immediate fsm call will send the swtich commands, the replies take some time.
👍 1
gaisser commented 2023-04-28 15:22:40 +02:00
Review
Copy Link

Ok

Ok
}
}
if (customRecoveryStates == POWER_SWITCHING_ON) {