CarbonixCubeOrange: fix inverted pwr monitor pins

[robertlong13]

Needs testing on hardware

[ghost]

Will test on my IronBird today and merge the code if working.

[ghost]

Thanks for the PR @robertlong13

[ghost]

recommended to put in the board detail
"Inverted the logic for the Brick and Aux valid pins for board version CX13042008 F and below"

[ghost]

Test Result on ironBird

[ghost]

[Jono453]

That screenshot looks better. I had error in the pixhawk carrier table with only Lipo - should be 3 not 1, 1 was with my test setup where I didn't have valid power on the Vservo line. I have correct it now in the confluence page. Ill add your ironbird test result there.

[Jono453]

For my understanding, the existing CubeOrange hwdef.dat already had

Power flag pins: these tell the MCU the status of the various power
supplies that are available. The pin names need to exactly match the
names used in AnalogIn.cpp.
PB5 VDD_BRICK_nVALID INPUT PULLUP
PB7 VDD_BRICK2_nVALID INPUT PULLUP

Did we miss this in the migration to Ardupilot 4.3 which caused the inverted result? The Schematic shows

which does appear to be pull-up already? Or does the supervisory circuit mess that up?

[robertlong13]

For my understanding, the existing CubeOrange hwdef.dat already had

Power flag pins: these tell the MCU the status of the various power supplies that are available. The pin names need to exactly match the names used in AnalogIn.cpp. PB5 VDD_BRICK_nVALID INPUT PULLUP PB7 VDD_BRICK2_nVALID INPUT PULLUP

Did we miss this in the migration to Ardupilot 4.3 which caused the inverted result? The Schematic shows which does appear to be pull-up already? Or does the supervisory circuit mess that up?

The existing hwdef does have these pins defined but has them defined as inverted logic. The net names in the CX13042008 schematic suggest they were intended to be inverted logic too, but the chip in question pulls low when the voltage is not detected, and floats and pulls high when the voltage is detected. This PR just redefines them to use the uninverted logic that the hardware has implemented. This isn't due to the migration to 4.3; it's always been messed up (I'm assuming).

We should add a comment in the schematic explaining this error in the labelling, and that we have compensated for it in software, but I don't think we should change the behavior in future revisions. Easier and better to keep all the board behaviors the same.