Cannot update QioTek Zealot H743 to ArduPlane 4.2.3 using standard options - Mac OSX issue?

I tried to flash the latest ArduPlane 4.2.3. When I tried on both QGroundControl (which I usually use) and also Mission Planner, both of them refused. Of course this is on my Mac(s) (I tried on both M1 Mac Pro and older Intel based MacBook Air). I don’t have or have access to a Windows machine.

QGroundControl kept insisting that I “please select board type” - even though it had correctly defaulted the board type and other information. Mission Planner told me straight out “ERROR - Firmware not available for this board” - but it is available:

I managed to install the firmware using Mission Planner by selecting “All Options” and manually choosing the board and version from the dropdown.

So - why do both QGroundControl and Mission Planner have a problem installing the standard firmware for this board, when clearly the firmware exists and can be installed?

1 Like

I wonder if this should be asked over on the Ground Control Software - ArduPilot Discourse forum?

I might try that, but I’m thinking that if the problem shows up in BOTH Mission Planner and QGroundControl, the problem is somewhere else. What is common? The firmware server!

If you try again now that the firmware is successfully loaded, does the GCS detect the board properly?

If not, what happens when you update the bootloader and try again?

The GCS is detecting the board properly already. Both pre and prior to the upgrade if you go to flash, it correctly identifies the board as QioTek Zealot H743 and populates that in the dropdown. (which you can see in the screenshots).

This same exact thing happened to me when I went to 4.2.2, but I didn’t get screenshots that time, so this time I made sure to capture it on the way through, I haven’t been game to update the bootloader because of the warning about potentially bricking my board.

So far as I know, the warnings are a little dated, and the bootloader update is pretty painless. I think it makes sense to try and update it, given the problem at hand.

How to update the boot loader on an ArduPilot autopilot - YouTube

I’ll take a look, but this is a very new board - it has only been supported since 4.2.0 so the bootloader should be quite up to date.

Understood. It’s also very possible that there’s a mismatched definition someplace. I’m following this board closely, as I think it has a lot of promise!

Where would I look for a “misplaced definition”?

Great question…and a bit beyond my scope of understanding. @hendjosh, any insight here?

I updated the bootloader it didn’t change anything. Note from the error message displayed by MP, it says:

ERROR: Firmware not suitable for this board fw:1024 - board 1036

I can see that this board id is 1036 according to the hwdef.dat file and board_types.txt. So I’m wondering where the 1024 is coming from?

According to the Mission Planner code this seems to be an integer (32 bit? 64 bit?) stored as the first 4? bytes of the raw firmware binary. The error message is thrown after comparing this integer (1024) to what the actual board is reporting (1036). So - I’d like to look in the apj file and see what those 4 bytes actually say. How can I do that?

1 Like

I used xxd to view the apj file. At the top I see this - which has the board_id correct as 1036, so the error message is wrong, the fw is 1036, not 1024! I think that Mission Planner (and QGC) may have a bug?

00000000: 7b0a 2020 2020 2262 6f61 7264 5f69 6422  {.    "board_id"
00000010: 3a20 3130 3336 2c0a 2020 2020 226d 6167  : 1036,.    "mag
00000020: 6963 223a 2022 4150 4a46 5776 3122 2c0a  ic": "APJFWv1",.
00000030: 2020 2020 2264 6573 6372 6970 7469 6f6e      "description
00000040: 223a 2022 4669 726d 7761 7265 2066 6f72  ": "Firmware for
00000050: 2061 2053 544d 3332 4837 3433 7878 2062   a STM32H743xx b
00000060: 6f61 7264 222c 0a20 2020 2022 696d 6167  oard",.

You don’t need a hex dump to read an apj file. It’s a JSON file, and the board id is human readable in a text editor.

However, I agree with your assessment - this looks like a bug someplace. Since QGC and MP both act the same, I wonder where else the board id is stored?

1 Like

Yes got it (see above).

It makes me wonder if other boards see this. Right now I’m thinking this is going to be a problem on any board with an id > 1024, has anyone else seen this?

I thought similarly until I took a look at just how many board IDs exceed that value - there are a lot!

mRoControlZeroOEMH7/hwdef-bl.dat:APJ_BOARD_ID	1024
mRoControlZeroOEMH7/hwdef.dat:APJ_BOARD_ID	1024
BeastH7/hwdef-bl.dat:APJ_BOARD_ID	1025
BeastH7/hwdef.dat:APJ_BOARD_ID	1025
BeastF7/hwdef-bl.dat:APJ_BOARD_ID	1026
BeastF7/hwdef.dat:APJ_BOARD_ID	1026
G4-ESC/hwdef-bl.dat:APJ_BOARD_ID	1027
G4-ESC/hwdef.dat:APJ_BOARD_ID	1027
FlywooF745/hwdef-bl.dat:APJ_BOARD_ID	1027
FlywooF745/hwdef.dat:APJ_BOARD_ID	1027
FreeflyRTK/hwdef-bl.dat:APJ_BOARD_ID	1028
FreeflyRTK/hwdef.dat:APJ_BOARD_ID	1028
luminousbee5/hwdef-bl.dat:APJ_BOARD_ID	1029
luminousbee5/hwdef.dat:APJ_BOARD_ID	1029
KakuteF4Mini/hwdef-bl.dat:APJ_BOARD_ID	1030
KakuteF4Mini/hwdef.dat:APJ_BOARD_ID	1030
PixC4-Jetson/hwdef-bl.dat:APJ_BOARD_ID	1032
PixC4-Jetson/hwdef.dat:APJ_BOARD_ID	1032
CubeOrange-joey/hwdef-bl.dat:APJ_BOARD_ID	1033
CubeOrange-joey/hwdef.dat:APJ_BOARD_ID	1033
Sierra-F9P/hwdef-bl.dat:APJ_BOARD_ID	1034
Sierra-F9P/hwdef.dat:APJ_BOARD_ID	1034
HolybroGPS/hwdef-bl.dat:APJ_BOARD_ID	1035
HolybroGPS/hwdef.dat:APJ_BOARD_ID	1035
QioTekZealotH743/hwdef-bl.dat:APJ_BOARD_ID	1036
QioTekZealotH743/hwdef.dat:APJ_BOARD_ID	1036
HerePro/hwdef-bl.dat:APJ_BOARD_ID	1037
HerePro/hwdef.dat:APJ_BOARD_ID	1037
MambaF405US-I2C/hwdef-bl.dat:APJ_BOARD_ID	1038
MambaF405US-I2C/hwdef.dat:APJ_BOARD_ID	1038
Nucleo-G491/hwdef-bl.dat:APJ_BOARD_ID	1040
Nucleo-G491/hwdef.dat:APJ_BOARD_ID	1040
mRo-M10095/hwdef-bl.dat:APJ_BOARD_ID	1041
mRo-M10095/hwdef.dat:APJ_BOARD_ID	1041
FlywooF745Nano/hwdef-bl.dat:APJ_BOARD_ID	1042
FlywooF745Nano/hwdef.dat:APJ_BOARD_ID	1042
HereID/hwdef-bl.dat:APJ_BOARD_ID	1043
HereID/hwdef.dat:APJ_BOARD_ID	1043
BirdCANdy/hwdef-bl.dat:APJ_BOARD_ID	1044
BirdCANdy/hwdef.dat:APJ_BOARD_ID	1044
Hitec-Airspeed/hwdef-bl.dat:APJ_BOARD_ID	1046
Hitec-Airspeed/hwdef.dat:APJ_BOARD_ID	1046
Nucleo-L496/hwdef-bl.dat:APJ_BOARD_ID	1047
Nucleo-L496/hwdef.dat:APJ_BOARD_ID	1047
KakuteH7/hwdef-bl.dat:APJ_BOARD_ID	1048
KakuteH7/hwdef.dat:APJ_BOARD_ID	1048
Sierra-L431/hwdef-bl.dat:APJ_BOARD_ID	1050
Sierra-L431/hwdef.dat:APJ_BOARD_ID	1050
Nucleo-L476/hwdef-bl.dat:APJ_BOARD_ID	1051
Nucleo-L476/hwdef.dat:APJ_BOARD_ID	1051
Sierra-F405/hwdef-bl.dat:APJ_BOARD_ID	1052
Sierra-F405/hwdef.dat:APJ_BOARD_ID	1052
HolybroG4_GPS/hwdef-bl.dat:APJ_BOARD_ID	1053
HolybroG4_GPS/hwdef.dat:APJ_BOARD_ID	1053
CarbonixL496/hwdef-bl.dat:APJ_BOARD_ID	1053
CarbonixL496/hwdef.dat:APJ_BOARD_ID	1053
MatekF405-TE/hwdef-bl.dat:APJ_BOARD_ID	1054
MatekF405-TE/hwdef.dat:APJ_BOARD_ID	1054
Sierra-F412/hwdef-bl.dat:APJ_BOARD_ID	1055
Sierra-F412/hwdef.dat:APJ_BOARD_ID	1055
BeastH7v2/hwdef-bl.dat:APJ_BOARD_ID	1056
BeastH7v2/hwdef.dat:APJ_BOARD_ID	1056
BeastF7v2/hwdef-bl.dat:APJ_BOARD_ID	1057
BeastF7v2/hwdef.dat:APJ_BOARD_ID	1057
KakuteH7Mini/hwdef-bl.dat:APJ_BOARD_ID	1058
KakuteH7Mini/hwdef.dat:APJ_BOARD_ID	1058
JHEMCU-GSF405A/hwdef-bl.dat:APJ_BOARD_ID	1059
JHEMCU-GSF405A/hwdef.dat:APJ_BOARD_ID	1059
SPRacingH7/hwdef-bl.dat:APJ_BOARD_ID	1060
SPRacingH7/hwdef.dat:APJ_BOARD_ID	1060
DevEBoxH7v2/hwdef-bl.dat:APJ_BOARD_ID	1061
DevEBoxH7v2/hwdef.dat:APJ_BOARD_ID	1061
MatekL431/	1062
MatekL431/	1062
CubeOrangePlus/hwdef-bl.dat:APJ_BOARD_ID	1063
CubeOrangePlus/hwdef.dat:APJ_BOARD_ID	1063
CarbonixF405/hwdef-bl.dat:APJ_BOARD_ID	1064
CarbonixF405/hwdef.dat:APJ_BOARD_ID	1064
FlyingMoonF407/hwdef-bl.dat:APJ_BOARD_ID	1067
FlyingMoonF407/hwdef.dat:APJ_BOARD_ID	1067
FlyingMoonF427/hwdef-bl.dat:APJ_BOARD_ID	1068
FlyingMoonF427/hwdef.dat:APJ_BOARD_ID	1068
MambaH743v4/hwdef-bl.dat:APJ_BOARD_ID	1073
MambaH743v4/hwdef.dat:APJ_BOARD_ID	1073
ReaperF745v2/hwdef-bl.dat:APJ_BOARD_ID	1074
ReaperF745v2/hwdef.dat:APJ_BOARD_ID	1074
PixSurveyA1/hwdef-bl.dat:APJ_BOARD_ID	1076
PixSurveyA1/hwdef.dat:APJ_BOARD_ID	1076
VRBrain-v51/hwdef-bl.dat:APJ_BOARD_ID	1151
VRBrain-v51/hwdef.dat:APJ_BOARD_ID	1151
VRBrain-v52/hwdef-bl.dat:APJ_BOARD_ID	1152
VRBrain-v52/hwdef.dat:APJ_BOARD_ID	1152
VRBrain-v54/hwdef-bl.dat:APJ_BOARD_ID	1154
VRBrain-v54/hwdef.dat:APJ_BOARD_ID	1154
VRUBrain-v51/hwdef-bl.dat:APJ_BOARD_ID	1351
VRUBrain-v51/hwdef.dat:APJ_BOARD_ID	1351
CubeOrange-periph-heavy/hwdef.dat:APJ_BOARD_ID	1400
CubeOrange-periph/hwdef-bl.dat:APJ_BOARD_ID	1400
CubeOrange-periph/hwdef.dat:APJ_BOARD_ID	1400
CubeBlack-periph/hwdef-bl.dat:APJ_BOARD_ID	1401
CubeBlack-periph/hwdef.dat:APJ_BOARD_ID	1401
Pixracer-periph/hwdef-bl.dat:APJ_BOARD_ID	1402
Pixracer-periph/hwdef.dat:APJ_BOARD_ID	1402
VRCore-v10/hwdef-bl.dat:APJ_BOARD_ID	1910
VRCore-v10/hwdef.dat:APJ_BOARD_ID	1910
modalai_fc-v1/hwdef-bl.dat:APJ_BOARD_ID	41775
modalai_fc-v1/hwdef.dat:APJ_BOARD_ID	41775

True but they are all very new.

There are a handful of F4 and F7 boards here that have been out for a couple of years. Some of the others would never manifest this problem, though, since there isn’t really an “easy” button for AP_Periph.

1 Like

1024 is one of those meaningful ‘computer/software’ numbers…just tossing that out, as I ordered the FC in question…

Completely understood, but appears it may be coincidence. The GCS software uses a long integer for that value, so it shouldn’t be truncated or clamped to a certain value so far as I can tell, and being clamped to 1024 would be very odd - 10 bit resolution would have a max value of 1023, and we rarely store integers in 10 bit words outside of ADC hardware.

1 Like