MATEK H743 Mini V3 - Board issues thread (discussion)

junwoo091400 commented 1 year ago

About

Out of PX4 supported boards, Matek H743-mini offers a benefit of small size, meanwhile providing powerful computation power and RAM, and FLASH space. However, is quite experimental (and not documented), and thus I wanted to compile list of things I noticed were wrong with the board in this issue to keep record.

Things that are not working

[ ] Default board when connected to QGC shows up as "PX4 DurandalV1"
[ ] Firmware flashing with "PX4 DurandalV1" detected isn't possible due to board ID mismatch
[ ] After flashing the bootloader, upon reboot board is recognized as "PX4 FMU V6U" (to be confirmed)
[ ] Flashing of the board isn't possible with default 57600 flightstack baud rate
[ ] IMUs onboard are different from Manufacturer website's speficiation

I will explain each problems in detail in separate chapters.

Board recognized as "PX4 DurandalV1"

This is happening because the USB connection (which supplies Vendor ID and Product ID) is returning 12642 and 75 each, which matches the "PX4 DurandalV1": https://github.com/mavlink/qgroundcontrol/blob/a07c4c257db1147e2eaa24608304642870cabcdf/src/comm/USBBoardInfo.json#L27

And I can confirm this, because the lsusb -v shows that the Vendor ID and product ID of the board is detected like so.

:crossed_fingers: Solution: we need to fix the prodcut ID and vendor ID of the CDACM config in the defconfig of the bootloader here: https://github.com/PX4/PX4-Autopilot/blob/7db667558ea4679554119a08caf4a8c464eab05d/boards/matek/h743-mini/nuttx-config/bootloader/defconfig#L33-L37

Note, however that after I changed that CDACM settings, I actually suffered from not being able to connect to the board for some reason, and had to revert those changes (maybe I didn't flash bootloader correctly :shrug:).

Firmware flashing not possible due to board ID mismatch

Found board id: 139,0 bootloader version: 5 on /dev/ttyACM0
WARNING: Firmware not suitable for this board (Firmware board_type=139 board_id=1013)

This is occuring as we don't have the match between the "board_id" in the firmware.prototype setting (which gets baked into .px4 file), and configuration of the Board ID that gets baked into the bootloader in hw_config.h.

That is, these two files: https://github.com/PX4/PX4-Autopilot/blob/7db667558ea4679554119a08caf4a8c464eab05d/boards/matek/h743-mini/firmware.prototype#L2

https://github.com/PX4/PX4-Autopilot/blob/7db667558ea4679554119a08caf4a8c464eab05d/boards/matek/h743-mini/src/hw_config.h#L99

Solution therefore is to change that BOARD_TYPE value, however, we need to figure out if 1013 is truly the correct value we should settle for (discussion below).

After flashing the bootloader, upon reboot board is recognized as "PX4 FMU V6U"

This is happening because after reboot of flashing the new bootloader, vendor ID and product Id is now recognized as 7052 and 54 for some reason, which matches PX4 FMU V6U: https://github.com/mavlink/qgroundcontrol/blob/fa9bf8a00fb064a8f4f9770894e1e019a581f72a/src/comm/USBBoardInfo.json#L17

The debug console of QGC shows the following info, which matches the assumption:

And it is really puzzling, as the steps are like following:

I re-flash the bootloader, and re-connect to QGC
QGC shows the board as "PX4 DurandalV1", and allows me to load .px4 firmware
After flashing and rebooting, when the board connects, the QGC detects the board as "PX4 FMU V6U" all of a sudden

This most likely means that during the .px4 binary flashing process, the Vendor ID and Product ID gets somehow re-written. And it does actually match the Product Id of the nsh (debug console), so I probably should test again the steps above with debug console disconnected, to make sure that QGC isn't detecting the debug console USB device first accidentally.

Flashing of the board isn't possible with default 57600 baud rate

As noted in https://github.com/PX4/PX4-Autopilot/issues/21925, the board upload command: make matek_h743-mini_default upload doesn't work, and I must call the script manually with 115200 baud rate setting:

python3 Tools/px_uploader.py --port /dev/ttyACM0 --baud-flightstack 115200 build/matek_h743-mini_default/matek_h743-mini_default.px4

This seems to just change the baud rate of the initial MAVLINK_REBOOT command being sent. However, I found that even with default flightstack baud rate, the reboot command seems to be received by the FC (shown on debug console), so not sure how this setting actually affects the flashing behavior :thinking:

IMUs are different than the specification

According to manufacturer's website, the ICM42688-P (SPI1) and ICM42605 (SPI4) should have been included:

However, when I check the board, I found that it simply had two ICM42688P sensors :disappointed:.

Therefore I had to change the rc.board_sensors to:

# Internal SPI bus ICM-42688P (SPI1), PITCH180
icm42688p -R 12 -b 1 -s start

# Internal SPI bus ICM-42688P (SPI4), PITCH180_YAW90
icm42688p -R 26 -b 4 -s start

For which, figuring out the rotation enum was quite a pain haha

Discussions

From the findings above, we arrive at some discussion points, which are:

What is the correct Vendor ID and product ID of CDACM of Matek H743 Mini V3?

Currently, the bootloader has 0x3162 and 0x004b for each, and the nsh (I guess this is for debug console, so doesn't really matter for user facing case?) has 0x1B8C and 0x0036 each.

The problem is that Matek doesn't officially have it's USB vendor ID registered in the USB database, like holybro has. So then it is both unclear which value it should really have.

There were some discussion that vendor Id should be 0x120A (same as Matek GNS-M8N), and product ID 0x03f5 (1013, in decimal).

What is the correct board ID for the Matek H743 Mini V3?

Assuming we decide on setting Board ID as 1013 for Matek H743 mini (as suggested here), we then face problem of all other Matek H743 variants having the same board ID, for example: https://github.com/PX4/PX4-Autopilot/blob/7db667558ea4679554119a08caf4a8c464eab05d/boards/matek/h743/firmware.prototype#L2

This is not ideal, as each unique board with unique firmware should have a different board ID, which is documented in QGC as well as in PX4-Bootloader.

So we should make decision on whether the MATEK H743 boards truly share the same board ID or not :shrug:

DronecodeBot commented 1 year ago

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-community-q-a-august-02-2023/33434/2

dirksavage88 commented 1 year ago

I had some experience with getting Matek GPS CAN node to run PX4 can node and eventually gave up on using it since it never worked correctly and Matek EOL'd the board around the time of the chip shortage.

The documentation was sufficient but I wish they put more thought into the design as I had issues with the onboard GPS that resulted in not being able to fly (safely). Others had reported similar issues with the same Matek can node.

PX4 / PX4-Autopilot