[WIP] Added STM32H7 support and Durandal

[davids5]

This is a work in progress

Todos: @bkueng - Updated!

• FLASH - NuttX driver for bootloader update
• Bootloader - Done [WIP] Adding STM32 H7 Nuttx Based bootloader  #13357
• Dcache - writeback mode
• fix free output - Done (see uptream https://bitbucket.org/nuttx/nuttx/pull-requests/1068/stm32h7-allocateheap-sram-and-sram1-are/diff)
• Update all board defconfigs
• Ensure worst case stack usage on PX4IO is AOK. (need test plan)
• CAN - uavcan
• full pin check out

[bys1123]

Wow, H7, looking forward to it!

[davids5]

@dagar -

1. I removed the bl_update on V2 Multicoptor anf V5 Stackcheck to fit.

2. Can you advise on the CI failures?
   a) How do I get the log from the MAC Build.
   b) the check_format http://ci.px4.io:8080/blue/organizations/jenkins/PX4%2FFirmware/detail/PR-13065/15/pipeline/26 It is suggesting the wrong thing!

3. Can we have @PX4/testflights begin flight testing?

4. Let's corodinate with @MaEtUgR on what GCC you feel we should use?
   is it https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
   See slack https://px4.slack.com/archives/C50RWGQMT/p1573060589119300 and [WIP] Compile PX4 on ARM GCC 9 #13375 (comment) for context.

@MaEtUgR any updates?

[julianoes]

1. removed the bl_update on V2 Multicoptor anf V5 Stackcheck to fit.

Isn't the bl_update mainly used on v2 because that's the boards that needs bootloader update.
On that note, we decided to stop worrying about fitting everything onto fmuv2 after v1.10.

[davids5]

1. removed the bl_update on V2 Multicoptor anf V5 Stackcheck to fit.

Isn't the bl_update mainly used on v2 because that's the boards that needs bootloader update.
On that note, we decided to stop worrying about fitting everything onto fmuv2 after v1.10.

I not sure if it is a problem. My thinking was that you can load the default build and do the update. then load the multicoptor. Is that not an ok path?

[julianoes]

Is that not an ok path?

Ok makes sense.

[dagar]

V2 Multicoptor mainly exists to make sure we don't introduce inter-dependencies between modules and vehicle types that would prevent doing these stripped down dedicated configurations. So I'd only worry about bl_update remaining in px4_fmu-v2_default as an upgrade path.

[davids5]

@dagar

Can you advise on the CI failures?
a) How do I get the log from the MAC Build

can you change this logs to be an artifact so we can see were is is failing?

[dagar]

@dagar

Can you advise on the CI failures?
a) How do I get the log from the MAC Build

can you change this logs to be an artifact so we can see were is is failing?

I think it's already showing the error.

make[1]: *** No rule to make target `/tmp/jenkins/workspace/sc_Firmware-compile_mac_PR-13065/build/px4_fmu-v5_default/NuttX/apps/libapps.a'

I'm taking a closer look.

[davids5]

@bkueng - rebased on master with latest Nuttx with PX4 contrib that fixes the dcache issue.
I have cleaned up the commit and forced pushed

Now the H7 is looking line the hot proc!

nsh> free
                               total       used       free    largest
Umem:       843136     164064     679072     480496
nsh>

  PID COMMAND                   CPU(ms) CPU(%)  USED/STACK PRIO(BASE) STATE FD
   0 Idle Task                    8914 63.240   200/  512   0 (  0)  READY  3
   1 hpwork                          0  0.000   344/ 1260 249 (249)  w:sig  3
   2 lpwork                          5  0.000   968/ 1516  50 ( 50)  w:sig  8
   3 init                         1299  0.000  2008/ 2604 100 (100)  w:sem  3
   4 wq:manager                      0  0.000   384/ 1252 243 (243)  w:sem  4
 168 wq:att_pos_ctrl               325  3.048  4768/ 6596 244 (244)  READY  4
  16 dataman                        30  0.000   752/ 1204  90 ( 90)  w:sem  4
  19 wq:lp_default                   0  0.000   780/ 1700 205 (205)  w:sem  4
  21 wq:I2C1                        35  0.261   788/ 1244 248 (248)  READY  4
  25 wq:hp_default                  80  0.783  1088/ 1500 243 (243)  w:sem  4
 126 wq:SPI1                      2851 21.951   892/ 1396 254 (254)  w:sem  4
 141 wq:I2C3                        24  0.261   920/ 1244 246 (246)  w:sem  4
 146 wq:SPI4                        24  0.261   624/ 1396 251 (251)  w:sem  4
 167 sensors                       153  1.306  1328/ 1964 237 (237)  READY 10
 419 log_writer_file                 0  0.000   368/ 1164  60 ( 60)  w:sem  3
 170 commander                      67  0.609  1544/ 3212 140 (140)  READY  6
 171 commander_low_prio              0  0.000   560/ 2996  50 ( 50)  w:sem  6
 172 wq:rate_ctrl                  270  2.700  1084/ 1596 255 (255)  w:sem  4
 216 gps                            10  0.087  1088/ 1540 208 (208)  w:sem  4
 245 mavlink_if0                   138  1.219  1616/ 2484 100 (100)  w:sig  4
 246 mavlink_rcv_if0                29  0.261  2680/ 3964 175 (175)  w:sem  4
 265 px4io                         159  1.480   884/ 1484 240 (240)  w:sem  4
 395 navigator                       6  0.087   920/ 1764 105 (105)  w:sem  4
 415 logger                         20  0.174  1280/ 3644 233 (233)  w:sem  3
 420 top                            13  0.000  1560/ 2028 248 (248)  RUN    3

Processes: 25 total, 6 running, 19 sleeping, max FDs: 20
CPU usage: 34.49% tasks, 2.26% sched, 63.24% idle
DMA Memory: 5120 total, 1024 used 1024 peak
Uptime: 14.695s total, 8.914s idle

Work Queue: 8 threads                      RATE        INTERVAL
|__ 1) wq:rate_ctrl
|   |__ 1) mc_att_control              999.9 Hz       1000.1 us
|   \__ 2) vehicle_angular_velocity    999.9 Hz       1000.1 us
|__ 2) wq:att_pos_ctrl
|   |__ 1) land_detector                50.0 Hz      19993.2 us (20000 us)
|   |__ 2) mc_pos_control               39.6 Hz      25230.4 us
|   |__ 3) ekf2                        248.8 Hz       4020.1 us
|   \__ 4) vehicle_acceleration        248.8 Hz       4019.6 us
|__ 3) wq:SPI4
|   \__ 1) ms5611                       99.6 Hz      10038.8 us
|__ 4) wq:I2C3
|   \__ 1) ist8310                      94.3 Hz      10607.8 us
|__ 5) wq:SPI1
|   |__ 1) bmi088                     1250.0 Hz        800.0 us (800 us)
|   |__ 2) bmi088                     1666.7 Hz        600.0 us (600 us)
|   \__ 3) mpu6000                    1250.0 Hz        800.0 us (800 us)
|__ 6) wq:hp_default
|   |__ 1) fmu                           0.0 Hz   28505414.0 us
|   |__ 2) adc                         100.0 Hz       9999.1 us (10000 us)
|   |__ 3) battery_status              100.0 Hz       9999.1 us (10000 us)
|   \__ 4) tone_alarm                   10.2 Hz      98393.6 us
|__ 7) wq:I2C1
|   |__ 1) ist8310                      94.3 Hz      10608.7 us
|   \__ 2) rgbled                       38.1 Hz      26230.7 us
\__ 8) wq:lp_default
    \__ 1) load_mon                      1.0 Hz     983863.3 us (1000000 us)

INFO  [sd_bench] Using block size = 4096 bytes, sync=0
INFO  [sd_bench]
INFO  [sd_bench] Testing Sequential Write Speed...
INFO  [sd_bench]   Run  0:   491.35 KB/s, max write time: 13 ms (= 307.69 KB/s), fsync: 5 ms
INFO  [sd_bench]   Run  1:   384.64 KB/s, max write time: 407 ms (=   9.83 KB/s), fsync: 5 ms
INFO  [sd_bench]   Run  2:   493.59 KB/s, max write time: 14 ms (= 285.71 KB/s), fsync: 5 ms
INFO  [sd_bench]   Run  3:   329.07 KB/s, max write time: 683 ms (=   5.86 KB/s), fsync: 5 ms
INFO  [sd_bench]   Run  4:   494.87 KB/s, max write time: 54 ms (=  74.07 KB/s), fsync: 5 ms
INFO  [sd_bench]   Avg   :   438.79 KB/s

[davids5]

@PX4/testflights - Please start testing on all FMUs

[jorge789]

Tested on PixRacer V4:
Modes Tested

Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.

- Procedure
Arm and Takeoff in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceeds to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint activate RTL.

Notes:
No issues noted good flight in general.

Log:
https://review.px4.io/plot_app?log=0cf7e75a-8599-46ab-b80f-d30dbc690a60

https://review.px4.io/plot_app?log=d01c358b-42db-4692-be82-0e50fd268a0f

Tested on Pixhawk V4 pro:
Modes Tested

Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.

- Procedure
Arm and Takeoff in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceeds to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint activate RTL.

Notes:
No issues noted good flight in general.

Log:
https://review.px4.io/plot_app?log=8d7cf522-b57f-4387-ba02-ee41da0298f8

Tested on NXP V3
Notes:
For some reason on QGC, I'm not able to upload the mission to the vehicle. I keep getting an error Mission transfer failed I tried it on the latest Beta, v1.10.0 (beta) (748b664) and the same error. I tried it on Stable firmware and it worked. I was able to upload the Mission on the first try.

@dagar what could be the issue with uploading the Mission on the NXP vehicle? I will continue to look into this tomorrow.

[davids5]

@PX4/testflights - Please test on K66, FMUv5

[LorenzMeier]

@davids5 How do we look on CAN here?

[davids5]

@LorenzMeier Staring it soon. Over 64 32 bit registers of new IP to learn.

[dannyfpv]

Tested on Pixhawk 4 v5 f-450

Flight Card 1

Modes Tested:
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.

Procedure:
Arm and Takeoff in position mode, after flying for approximately one minute, switched to altitude then stabilized mode.

Notes:
No issues were noted, good flight in general.

Logs:

https://review.px4.io/plot_app?log=f60541fa-260a-4265-8e73-97878a0febea

Flight Card 2

Modes Tested
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure

Armed form QGC.
Took-off on mission plan mode
Note that commands were sent form QGC (Armed and takeoff)
Once all waypoint completed vehicle switched to RTL and landed as expected.
Good flight in general.

Note:
No issues were noted, good flight in general.

Logs:
https://review.px4.io/plot_app?log=4335f025-fdac-4f88-833d-8b59d94e6bf6

Flight Card 3
Modes Tested
Position Mode: Good.
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure
Arm and Takeoff in position mode, after flying for approximately one minute, switched to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint.

Note:
No issues were noted, good flight in general.

Logs:
https://review.px4.io/plot_app?log=fbe097f7-0ec6-4fad-9c99-2df37c6604c5

Flight Card 4
Modes Tested
Fail-safe: The radio control turned off and the vehicle returned and landed correctly.
Tested good.

Logs:
https://review.px4.io/plot_app?log=09267eb9-b46b-40c3-ad1a-2d28b8aee9a9

[davids5]

@mrpollo we should test K66, V4, V2 as well - then we can merge.

[davids5]

NuttX 8.2 is releasing this weekend. So I will rebase on master Firmware and Update to 8.2 Nuttx. Then we can retest.

[LorenzMeier]

@mhkabir Did you send the heater changes as PR? I must have missed it.

[LorenzMeier]

I did a review of the main diff trying to ensure there are no regressions for existing boards. I have reviewed the newly added code for Durandal on a high-level for basic logic errors.

[LorenzMeier]

@mhkabir Could you send a PR with the right device ID you used to track for this param? SENS_TEMP_ID

[jorge789]

Tested on NXP_FMUK66_V3

Flight Card 1

Modes Tested:
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.

Procedure:
Arm and Takeoff in position mode, after flying for approximately one minute, switched to altitude then stabilized mode.

Notes:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=953c82a8-4f25-4239-87e7-a970ac606f99

Flight Card 2

Modes Tested
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure

Armed form QGC.
Took-off on mission plan mode
Note that commands were sent form QGC (Armed and takeoff)
Once all waypoint completed vehicle switched to RTL and landed as expected.
Good flight in general.

Observations: When the vehicle was landing, it did not descend vertically, drifted away with the wind and landed the vehicle manually.

Logs: https://review.px4.io/plot_app?log=792db7ac-8738-4bdd-8a03-aa6d88b371b3

Flight Card 3
Modes Tested
Position Mode: Good.
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure
Arm and Takeoff in position mode, after flying for approximately one minute, switched to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint see landing behavior.
Good flight in general.

Note:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=7f174e97-c897-4003-b818-14858acf2817

@davids5 we also tested Flight card 4(Failsafes) but the log did not get stored on the SD card. We have noticed that on some flights, for example, testing Master or Stable some logs don't get stored.
We initially thought the SD card was the issue, so we replaced it but we noticed today the log did not get saved.

[mhkabir]

@LorenzMeier I'm making a PR for sensor ID autodetection. Just setting the ID in the startup script is too prone to the ID getting changed and then the functionality just breaking silently.

[LorenzMeier]

I would factor this out from this though.

[davids5]

The Sensor & Heater's location is defined by the board's layout. I would tie it to the SPI bus/chip select ID not the sensor type.

[mhkabir]

@davids5 the device ID is based on the bus and chip select - what am I missing? Is there a particular way you'd like to see it implemented?

@LorenzMeier yes that was the plan - do you want me to make a temporary PR just setting the device ID to the ICM chip in rc.board_defaults?

[davids5]

@mhkabir I am not clear on the goal so let me know if I am off base

Here is what I can tell you.

There is the following on the IMU board.

1. TMP121, 1.5 Degree Accurate Digital Temperature Sensor with SPI Interface on SPIAUX_CS_MEM (CS3)
2. BMI088 - SPI1_CS4_BMI055_ACC (CS2) & PI1_CS3_BMI055_GYRO (CS1)
3. ICM20689 SPI1_CS1_ICM20689 (CS0)
4. 1W Max heating resistor

All of the IC's a subject to the heating. So if the ID & ~(CS|SPIBUS) == SPI1 it is heated.
ID & ~(TYPE) would tell you what profile to apply.

[davids5]

@jorge789

@davids5 we also tested Flight card 4(Failsafes) but the log did not get stored on the SD card. We have noticed that on some flights, for example, testing Master or Stable some logs don't get stored.
We initially thought the SD card was the issue, so we replaced it but we noticed today the log did not get saved.

Is this only on K66 ?

[Tony3dr]

@jorge789

@davids5 we also tested Flight card 4(Failsafes) but the log did not get stored on the SD card. We have noticed that on some flights, for example, testing Master or Stable some logs don't get stored.
We initially thought the SD card was the issue, so we replaced it but we noticed today the log did not get saved.

Is this only on K66 ?

@davids5, correct only for the NXP FMUK66 vehicle.

[bys1123]

How to set TRIG_PINS on Durandal? It have no AUX6.

[klxing]

eleasing this weekend. So I will rebase on master Firmware and Update to 8.2 Nuttx. Then we can retest.

Hey David
Can we use CAN port on pixhawk v6x now? Science I can't find stm32_can.c in stm32h7 like files as in stm32f7, and it will report errors when I open "/dev/can0"
Is there any method that I can send messages to control the motors on my rover? Thanks