We have had a report of control surfaces not moving on IOMCU connected servos in a pre-flight check.
@peterbarker and I have also seen this once on an aircraft in Canberra, although we did not capture a log (we had assumed it was a hardware issue and were very surprised to find a reboot fixed it).
My current guess is that one of the configuration registers in the IOMCU is not being transferred correctly. For example, if PAGE_REG_SETUP_CHANNEL_MASK was transferred incorrectly then it would cause exactly these symptoms, as it would disable some channels. These type of config registers are only sent when they change, and the transport CRC is quite weak (just 8 bit). It is possible that a bad transfer could cause this issue.
In the log from the affected user SERVO_GPIO_MASK is set to 15360, which is Servo 11|Servo 12|Servo 13|Servo 14. A single bit corruption in this value would cause the symptoms of one aileron not moving.
I think we need some way of confirming the correct configuration:
Maybe a 32 bit CRC of all expected config registers and re-send if not correct? Maybe only do this when disarmed?
We could store a mirror of the expected config values in the FMU, and have a 1Hz fetch of the current CRC on the IOMCU, triggering a resend if needed.
Alternatively we could just have a list of registers we confirm in a cyclic fashion while disarmed?
We have had a report of control surfaces not moving on IOMCU connected servos in a pre-flight check.
@peterbarker and I have also seen this once on an aircraft in Canberra, although we did not capture a log (we had assumed it was a hardware issue and were very surprised to find a reboot fixed it).
My current guess is that one of the configuration registers in the IOMCU is not being transferred correctly. For example, if PAGE_REG_SETUP_CHANNEL_MASK was transferred incorrectly then it would cause exactly these symptoms, as it would disable some channels. These type of config registers are only sent when they change, and the transport CRC is quite weak (just 8 bit). It is possible that a bad transfer could cause this issue.
In the log from the affected user SERVO_GPIO_MASK is set to 15360, which is Servo 11|Servo 12|Servo 13|Servo 14. A single bit corruption in this value would cause the symptoms of one aileron not moving.
I think we need some way of confirming the correct configuration:
Maybe a 32 bit CRC of all expected config registers and re-send if not correct? Maybe only do this when disarmed?
We could store a mirror of the expected config values in the FMU, and have a 1Hz fetch of the current CRC on the IOMCU, triggering a resend if needed.
Alternatively we could just have a list of registers we confirm in a cyclic fashion while disarmed?