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: https://firmware.ardupilot.org/Plane/stable-4.2.3/QioTekZealotH743/
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?
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!
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.
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!
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?
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?
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?
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?
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.
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.
