fmu-v5: Updated board config to RC01 of FMUv5 Spec #7219

simonegu · 2017-05-11T18:25:48Z

N.B. HW that is not compatible with the FMUv5 RC01 specification: I.E HW at RC00 or test HW will no longer function when this is merged. FYI: @sirPerna

@davids5 I started updating the board_config.h for fmu-v5, please have a look.

@simonegu, this is ready, or should I say ready enough. There is more to do, but it is solid base line.

Thank you for doing the RC01 update!

simonegu · 2017-05-15T07:30:21Z

@davids5 I have a couple of questions:

do we need to change GPIO_nVDD_BRICK_VALID to GPIO_nSPI5_RESET_EXTERNAL1 ?
Yes
Set up SPI5
check configuration of GPIO_SPI5_DRDY7_EXTERNAL1
https://github.com/PX4/Firmware/blob/4e04bd26e98e0494fcd90a356469dc5a9dd3e979/src/drivers/boards/px4fmu-v5/board_config.h#L96
It should be grouped by bus.
PF12 (output) and PF13 (input) need configuration?
Yes
PH15 / SPI5_SYNC_EXTERNAL1 needs to be configured?
Yes

davids5 · 2017-05-15T15:13:32Z

@simonegu Answers are inlined above

simonegu · 2017-05-16T12:14:56Z

@davids5 a couple of questions:

do we need to change GPIO_nVDD_BRICK_VALID to GPIO_nSPI5_RESET_EXTERNAL1 ?

Do we simply forget the VDD_BRICK_VALID? In other words, this is not handled anymore?

PF12 and PF13 need configuration?

How should they get configured? As a standard input (GPIO_INPUT|GPIO_PULLUP)?

PH15 / SPI5_SYNC_EXTERNAL1 needs to be configured?

davids5 · 2017-05-16T15:06:53Z

@simonegu - Just to close the loop.

Please refer to the FMUv5 Pinchart

do we need to change GPIO_nVDD_BRICK_VALID to GPIO_nSPI5_RESET_EXTERNAL1 ?

Do we simply forget the VDD_BRICK_VALID? In other words, this is not handled anymore?

See Tab "RC00 to RC01" for the changes

PF12 and PF13 need configuration?

How should they get configured? As a standard input (GPIO_INPUT|GPIO_PULLUP)?

See "All pinouts" for the signal type and usage.

PH15 / SPI5_SYNC_EXTERNAL1 needs to be configured?

Should it be configured as a standard output? (GPIO_OUTPUT|GPIO_PUSHPULL|GPIO_SPEED_2MHz|GPIO_OUTPUT_SET|PORT|PIN)

davids5 · 2017-06-23T17:50:26Z

rebased on master f82e85f

davids5 · 2017-06-24T16:07:56Z

SD CARD:There were a series of cascading failures. The newly added SPI5 failed to init, so it skipped the SD CARD Init. Once that was fixed, the root cause was not not turning on the SD Card Power. The polarity changed on test hw to match spec (active high). master had active low and worked by default. It never invoked the SD_CARD_POWER_CTRL(true)

davids5 · 2017-06-30T13:21:29Z

@dagar - would you please have a look at commits: 083979c..62085f9 once this comes into master we would want to continue the Power and Battery refactoring we discussed. (Adding per Brick params etc)

@klopezal This implement:

Backward compatible N Brick Support FMUV4pro & FMUv5
The proposed fix for motors spin when rebooting
Would you please test this for the issues 3,4 listed here

davids5 · 2017-06-30T13:30:36Z

@PX4TestFlights - Please bench test on all variants of HW with different FMU versions and platforms.

Please focus on battery indication. Testing Low voltage behaviour (QGC, Lights, sounds) is consistent with master. Use 1 and 2 bricks on FMUv4Pro. With 1 Brick try it plugged into both power 1 and 2.

bkueng · 2017-06-30T14:11:30Z

src/modules/sensors/sensors.cpp

+									ctrl.control[actuator_controls_s::INDEX_THROTTLE],
+									_armed,  &_battery_status[b]);
+					int instance;
+					orb_publish_auto(ORB_ID(battery_status), &_battery_pub[b], &_battery_status[b], &instance, ORB_PRIO_DEFAULT);


This will publish to multiple instances. Will there be a common place for voting, so that e.g. commander always uses the selected one? Or will it need to subscribe to all instances?

See 88ead15 for how it works. It is a interim bridge.

Ah, I should have looked at it more closely, thanks!

davids5 · 2017-06-30T14:21:42Z

@simonegu - first post has been updated.
Note the breaking change notice. It should not affect the HW you have.

dagar · 2017-06-30T14:22:55Z

src/modules/sensors/sensors.cpp

-				orb_publish_auto(ORB_ID(battery_status), &_battery_pub, &_battery_status, &instance, ORB_PRIO_DEFAULT);
+					/* Consider the brick connected if there is a voltage */
+
+					bool connected = bat_voltage_v[b] > 1.5f;


Do we actually need connected? What if it just wasn't published if not connected?

I think that's a great fundamental question for most hardware in the system. FMUv5 establishes the notion of being able to determine if a piece of hardware is expected to be in the system.

a) is present in functioning correctly.
b) expected to be there but is not.

battery(ies) can be connected to the system and Vbat >= Vconnected (SW) and Vbat < Vvalid (HW). This allows us to log that fact. I would like to have a param per/brick for Vconnected

But you tell me if it make sense.

santiago3dr · 2017-06-30T22:11:49Z

couple flights running on pixracer (V4)
http://logs.px4.io/plot_app?log=14893eb8-2d18-4c37-ac37-18430461efd4
http://logs.px4.io/plot_app?log=617ca81a-b573-4ea3-b1c2-1f5114cea61d

proper firmware flash, led/buzzer activity
good flight; stabilize, altitude, position and rtl all check out
voltage readings look accurate when compared to battery checker readings

santiago3dr · 2017-06-30T23:04:33Z

indoor hover test on pixhawk mini (V3)
http://logs.px4.io/plot_app?log=f14cc211-860f-4217-a53e-a7c913bddc79

calibrated voltage scaling; seconds after take-off, low battery warning kicked in despite battery being nearly full

davids5 · 2017-07-02T01:24:40Z

@santiago3dr - Do you have FMUV1 and FMUV4PRO, Snapdragon, and aerofc HW you can just check battery readings on?

Since Hardware flow control has not been enabled this typo survived.

The LTC4417 provides a valid signal for USB. This change configures the GIOP and provides 1) True logic macro to read the pin and the IOCTL defines to read it from the FMU. The macro will return true when the signal is active (low on the LTC4417). The IOCTL will read be the actual pin state.

The V4 HW replaced the LTC4417 provided valid signal for USB. with an active high, version. This commit configures the GIOP and provides 1) a MACRO to read the pin and the IOCTL defines to read it from the FMU. The macro result true logic: true when the signal is high. The IOCTL read would be the actual pin state.

The LTC4417 provides a valid signals for brick1, brick 2 and USB This change configures the GIOP and provides 1) a MACRO to read the pin and 2) the IOCTL defines to read it from the FMU. The macro's result is true logic: It is true when the signal is active. (Active low on the the LTC4417). The IOCTL read would be the actual pin state.

As done on fmuV4 on resets invoked from system (not boot) insure we establish a low output state (discharge the pins) on PWM pins before they become inputs as a result of the pending reset. We also delay the reset by 400 MS to insure the 3.1 Ms pulse is not too close to the last PWM pulse.

Added comments to ADC defines with Pin numbers. Added the GPIO_HW_{REV:VER}_DRIVE signals Define the GPIO_nPOWER_IN_{A:C] and assign them to BRICK1, BRICK2 and USB Valid. Regroupped power signals and defined true logic Power Control macros in the arch agnostic form. Defined the same IOCTL defines for FMU GPIO IOCTL Use the power Control macros on board_app_initialize

Dispite what the ref manaul says. Some HW needs the added pull down to insure the pin reads low when not plugged in to USB.

The PX4IO is an population option on some varients. To have 1) FMU only control 2) IO Only control 3) FMU fall back control These pins need to come up as inputs, until the configuration is determined.

system_source - This battery status is for the brick that is supplying VDD_5V_IN priority - Zero based, This battery status is for the brick that is connected to the Power controller's N-1 priority input. V1..VN. 0 would normally be Brick1, 1 for Brick2 etc Battery now assigns connected from the api in the updateBatteryStatus, as well as system_source and priority

FMUv4Pro and FMUv5 Spec added multi brick support FMUv5 added SCALED_VDD_3V3_SENSORS This change provides legacy (FMUv2) defaults for Power Bricks and Sensor rail volatage source.

This change implements the publishing of batery_status messages for each brick on the system, using multi-pub. Backward compatiblity is achived by always publishing the batery_status of the bick that has been selected by the HW Power Controller (PC) on instance 0. The batery_status.system_source will be true in one and only one batery_status publication when a valid bit is set in system_power.brick_valid. However, if USB is connected, and both brikcs are not providing voltages to the PC that are in the Under/Over Voltage Window (set in HW) the system_source may be false in all publications.

voltage3V3_v - the sensor 3.3V voltage rail v3v3_valid - the value of voltage3V3_v may be 0. This field is a 1 when the HW provides voltage3V3_v brick_valid - is now a bit mask. A 1 in the postion inticate the Power controler HW has a valid supply voltage present (in V window) on that priority (channel V1..Vn). The mapping is formed by 1<<battery_status.msg.priority or using the manifest constanst BRICKn_VALID_MASK usb_vaild - is now indicated from the Power controler HW or the usb_connected if Power controler is not present. brick_valid == 0 and usb_vaild = 1 implies the FMU is powered from USB only brick_valid != 0 and usb_vaild = 1 implies the FMU is powered from the higest priority brick, providing a 1 bit in brick_valid and from USB

Removed unused headers and placed the __BEGIN_DECLS where it belonged

BOARD_HAS_LTC44XX_VALIDS - 0 -> No LTC44xx IC, N is the number of Power Bricks connected to the LTC44xx For a LTC4417 this would be 2 as the third prioriy is used for USB BOARD_HAS_USB_VALID - If defied as 1 imples that infact the USB has a priority connection on the LTC44XX BOARD_HAS_NBAT_V - the number of battery voltage sensing chennels on the ADC BOARD_HAS_NBAT_I - the number of battery current sensing chennels on the ADC A super simple (non FMUv5 compliant) board with no LTC44xx and just one battery that have no current sense: BOARD_HAS_LTC44XX_VALIDS = 0 BOARD_HAS_USB_VALID = 0 BOARD_HAS_NBAT_V = 1 BOARD_HAS_NBAT_0 = 0 A fully FMUv5 compliant design would use: BOARD_HAS_LTC44XX_VALIDS = 2 BOARD_HAS_USB_VALID = 1 BOARD_HAS_NBAT_V = 2 BOARD_HAS_NBAT_0 = 2 These setting properly condition the ADC channles and all the Power module valid sensing logic in the ADC module.

Both PX4Test and Beat noted if only Brick to was connected battery_status Intance 0 voltage was 0V for Brick2 The priority selection logic is run prior to the subscription creation and only updated the priority on a change. Before the subscriotions were created. _battery_pub_intance0ndx is suposed track the location in the _battery_pub array that is instance 0. It is then used to associate (move) instance 0 with (to) the lowest brick (highest priority in HW) brick that is selected in HW. The Bug was that before the subscriptions are created, _battery_pub_intance0ndx set to 1. And then and never updated. The fix was to only run the priority selection logic once the subscriptions are created.

davids5 · 2017-07-17T20:32:15Z

Done

LorenzMeier · 2017-07-17T21:24:45Z

Jenkins test this please.

LorenzMeier · 2017-07-17T21:25:13Z

@dagar looks like Jenkins became flaky recently. I will have an eye on it.

simonegu requested a review from davids5 May 15, 2017 11:05

simonegu force-pushed the fmuv5_update_board_config branch 2 times, most recently from 9bb6c6c to e7d7f32 Compare May 23, 2017 06:41

simonegu force-pushed the fmuv5_update_board_config branch 2 times, most recently from bad6719 to 04627b7 Compare June 19, 2017 08:02

davids5 force-pushed the fmuv5_update_board_config branch from 04627b7 to f956fea Compare June 23, 2017 17:50

davids5 force-pushed the fmuv5_update_board_config branch 2 times, most recently from ca3ae61 to 878817c Compare June 24, 2017 15:56

davids5 force-pushed the fmuv5_update_board_config branch from 878817c to 62085f9 Compare June 30, 2017 13:03

davids5 mentioned this pull request Jun 30, 2017

px4fmu-v4pro board_config: swap BRICK1 with BRICK2 #7442

Merged

davids5 changed the title ~~DO NOT MERGE: fmu-v5: started updating board config to newest specs~~ fmu-v5: Updated board config to RC01 of FMUv5 Spec Jun 30, 2017

davids5 requested review from dagar, bkueng, LorenzMeier and klopezal June 30, 2017 13:31

bkueng reviewed Jun 30, 2017

View reviewed changes

dagar reviewed Jun 30, 2017

View reviewed changes

davids5 mentioned this pull request Jun 30, 2017

Issues found with Pixhawk 3 Pro #7431

Closed

David Sidrane added 23 commits July 17, 2017 10:31

px4fmu-v5:Turn On SD card

9d2570f

px4fmu-v2:nuttx config fix typo GPIO_USART6_CTT->GPIO_USART6_CTS

f296000

Since Hardware flow control has not been enabled this typo survived.

px4fmu-v5:Removed unused LED alias defines.

75c46b2

px4fmu-v5:SPI chip selects per FMUv5 Spec

b2b7b01

px4fmu-v5:Define the FMU_CAP[1:3] per FMUv5 Spec

1fa1f73

px4fmu-v5:Define UI LEDs per the FMUv5 Spec

bec3eeb

px4fmu-v5:Define Tone Alarm in terms of the FMUv5 Spec

f568de4

px4fmu-v5:formatting

e1b6b0f

px4fmu-v5:Insure the VBUS signal is low if USB is not connected.

3f37a42

Dispite what the ref manaul says. Some HW needs the added pull down to insure the pin reads low when not plugged in to USB.

px4fmu-v5:There will be variants that will [not]have the PX4IO.

3bb3595

The PX4IO is an population option on some varients. To have 1) FMU only control 2) IO Only control 3) FMU fall back control These pins need to come up as inputs, until the configuration is determined.

board_common:Define defaults for Power Bricks and Sensor rail volatage

ae4a6b1

FMUv4Pro and FMUv5 Spec added multi brick support FMUv5 added SCALED_VDD_3V3_SENSORS This change provides legacy (FMUv2) defaults for Power Bricks and Sensor rail volatage source.

px4fmu-v5:board_config clean up

41e4bfa

Removed unused headers and placed the __BEGIN_DECLS where it belonged

system_power:Add blank line per review

addae02

davids5 force-pushed the fmuv5_update_board_config branch from 010a1a0 to addae02 Compare July 17, 2017 20:32

LorenzMeier approved these changes Jul 17, 2017

View reviewed changes

davids5 merged commit 9635ec4 into master Jul 18, 2017

simonegu deleted the fmuv5_update_board_config branch July 18, 2017 08:30

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fmu-v5: Updated board config to RC01 of FMUv5 Spec #7219

fmu-v5: Updated board config to RC01 of FMUv5 Spec #7219

simonegu commented May 11, 2017 •

edited by davids5

Loading

simonegu commented May 15, 2017 •

edited by davids5

Loading

davids5 commented May 15, 2017

simonegu commented May 16, 2017

davids5 commented May 16, 2017

davids5 commented Jun 23, 2017

davids5 commented Jun 24, 2017

davids5 commented Jun 30, 2017

davids5 commented Jun 30, 2017

bkueng Jun 30, 2017

davids5 Jun 30, 2017 •

edited

Loading

bkueng Jun 30, 2017

davids5 commented Jun 30, 2017

dagar Jun 30, 2017

davids5 Jun 30, 2017

santiago3dr commented Jun 30, 2017

santiago3dr commented Jun 30, 2017

davids5 commented Jul 2, 2017

davids5 commented Jul 17, 2017

LorenzMeier commented Jul 17, 2017

LorenzMeier commented Jul 17, 2017

fmu-v5: Updated board config to RC01 of FMUv5 Spec #7219

fmu-v5: Updated board config to RC01 of FMUv5 Spec #7219

Conversation

simonegu commented May 11, 2017 • edited by davids5 Loading

N.B. HW that is not compatible with the FMUv5 RC01 specification: I.E HW at RC00 or test HW will no longer function when this is merged. FYI: @sirPerna

simonegu commented May 15, 2017 • edited by davids5 Loading

davids5 commented May 15, 2017

simonegu commented May 16, 2017

davids5 commented May 16, 2017

davids5 commented Jun 23, 2017

davids5 commented Jun 24, 2017

davids5 commented Jun 30, 2017

davids5 commented Jun 30, 2017

bkueng Jun 30, 2017

Choose a reason for hiding this comment

davids5 Jun 30, 2017 • edited Loading

Choose a reason for hiding this comment

bkueng Jun 30, 2017

Choose a reason for hiding this comment

davids5 commented Jun 30, 2017

dagar Jun 30, 2017

Choose a reason for hiding this comment

davids5 Jun 30, 2017

Choose a reason for hiding this comment

santiago3dr commented Jun 30, 2017

santiago3dr commented Jun 30, 2017

davids5 commented Jul 2, 2017

davids5 commented Jul 17, 2017

LorenzMeier commented Jul 17, 2017

LorenzMeier commented Jul 17, 2017

simonegu commented May 11, 2017 •

edited by davids5

Loading

simonegu commented May 15, 2017 •

edited by davids5

Loading

davids5 Jun 30, 2017 •

edited

Loading