Error 404 when getting firmware

I’ve just installed Mission Planner to set up my new Pixhawk 4 and I get error 404 when the Set up Wizard tries to download the Hexcaopter firmware. I’ve tried version 1.3.58 and the beta and I have tried both the MSI installer and the zip version. I am running windows 10.

Searching has shown other messages about 404 errors but non that I could see for firmware. Any help appreciated.

image

I just got a new Windows 10 laptop so I can try some of these problems for myself. It does appear Mission Planner latest beta does not want to load firmware in a FMUv5 controller (CUAV Pixhack V5 in my case).

No%20Firmware

However, the daily build of QGroundControl installs the firmware with no issues, no jumping thru hoops, no hassles.

Hi Chris
That is exactly what I am doing at the moment. I am testing between firmware versions to see what is working and what not (hardware mainly in ChibioOS) on my Helicopters.
For some reason MissionPlaner sometimes is not want to install a chosen firmware. I open Qgroundcontrol and always no hassle to install.
But I still like MissionPlaner for many reason.

I do not know what the problem is at the present time with MP. My computer says it is not available. But the build is definitely in the correct location at firmware.ardupilot.org and it is the correct 3.6rc10. Which is also where QGC is getting it from.

Thanks for the replies, I’m new to all this so I’m not really sure how best to proceed, should I use Qgroundcontrol for the time being?

I have the trio of GCS’s installed (MP, QGC and APM) and whenever I find that something is not working in one of them I switch to the others. Sometimes things are moving fast with ArduPilot and GCS’s lag behind…

Thanks, that’s good to know

you get the 404 because there is no stable release of the firmware for that board.

ie if you use the beta firmware, all of the above will work. my guess is the QGC is installing the beta firmware, not stable

and the screenshot shows exactly that. 3.6.0-rc10. is a beta firmware, not stable.
use the beta firmware link in MP, and it will work fine.

Thanks, I’ll try the beta tonight.

That’s what I did. I clicked on beta, and if you see in my screenshot it selected 3.6.0-rc10 heli. I got a message as shown - no firmware available for this board. I loaded 3.6-rc9 in it with MP and it worked a couple weeks ago, but that was running MP on linux, not Windows. I didn’t verify if it works on linux or not to load 3.6-rc10. I don’t totally trust Windows is not blocking external connections sometimes. Even though I told it at install to unblock external connections. Linux is far more reliable.

what board are you testing against? just want to confirm

It is a CUAV Pixhack V5. Before we get too excited about it being a problem with Mission Planner, let me check when I get home for lunch to see if I can install the firmware with MP on linux. I’ve used MP on linux right along and never had a problem since support was put in for the FMUv5 boards. This is the first time I’ve tried it on Windows, as I just got a new laptop with Win10 in it. So I strongly think this could be a problem with Windows itself blocking ports or access to outside services. I had removed all the anti-virus crap that ships in this thing, and yet last night when I tried to installed QGC daily build “Windows Defender” pops up and says, “not gonna happen - bad program”. I’m not a Windows user so not familiar with all this cruft that Windows has in it. If it works on linux, then it’s not a problem with MP.

I’ll report back on that when I can get a chance to try it on linux.

Just an update, loading the beta firmware worked. For anyone who stumbles across this in Mission Planner -> Inital Setup ->Install Firmware, at the bottom, just right of centre is “Beta firmwares”

@Michael_Oborne I tried it on Linux and it loaded firmware fine - build 1.3.580. So I reverted back to rc9 on Linux from one of my dev builds. Went to the Windows computer and tried it and this time it loaded firmware (build 1.3.6794.30567) but it did not load the heli firmware I selected. Not quite sure what it loaded, as there was no H_ params for helicopters, and I got an error when I connected to the board complaining that it did not know what the frame class is.

Reloaded the firmware with QGC and then everything was fine again - got the proper helicopter firmware I selected to install.

So tried it by downloading the firmware first and using install custom firmware. On Linux using build `1.3.580 it installs fine. On Windows with the above noted build it fails to identify the board - it says no response from board.

This probably doesn’t help much, just some experiments I tried here. There is some strangeness with Windows and its DOS-style COM ports that Linux does not use. I’ve been able to load firmware before with MP on Linux while other users have noted their board is not identified, or no response from it, on Windows. I can put that latest build in my Linux dev machine this evening and try it again, but I have yet to ever have a problem with MP on Linux, so it will likely be no different.

Maybe somebody who is more versed in the strangeness of how Windows does things can shed some light on it.

  • fails to identify the board -.
    That’s it Chris. Most the time but not always that comes up. I use QGC and that finds the board immediately on the same Window 10 PC strait after MP could not do it.

Except I don’t know what’s causing it, Fred. On Linux running the same build of Mission Planner it detects it straight away and installs firmware fine. Windows plays tones or something when I plug the board in. Linux doesn’t do that sort of stuff. But I notice when I unplug the board and then click OK to have it detected I get the tones on Windows twice - once when I plug it, and then it almost immediately makes another tones which means it disconnected by itself. So, of course, that being the case, MP is not going to be able to detect the board.

Since Linux doesn’t do that and seems to work when Windows don’t, it sort of indicates to me that there’s some sort of problem with Windows and it’s so-called “com ports”. Or some issue with drivers maybe. I don’t know. I notice on Windows installing MP installs a bunch of “drivers”. That stuff is not required on linux - it’s all built into the kernel in linux with loadable kernel modules.

Chris,
on my PC it is only during firmware upgrade. I can connect both Pixhawk 2.1 to MP for GC purpose, no problem.
If I want to change FW after a normal disconnection MP is suddenly not recognizing the board.
I do have Windows 10 (latest) no other OP and the PC is not even a year old and granty.
After that I change to QGC and never had a situation that QGC could not recognizing the board on the same PC.
Turning the PC off, rebooting, but the same thing during FW with MP. I believe I have not seen that happen in the past than this year.
Installed is a powerful Internet security sw. running in the background. Most other stuff is working really fine in MP.
I like the replay of the tlog files of my Heli testing with the sensors showing in real time what the FC in the Heli is doing during the test flights, hover and so on. Very powerful feature. I like MP alone for that.
edit: Now 1 hour later after I wrote the above.
I wanted to change in the TR600 the FW from 3.6.rc9 Nuttx to 3.6.rc10 ChibioOS. I did it with MP and it worked first time.
The conclusion is: it is not repeatable.
How many times is Microsoft sticking it’s dirty nose into the PC-Window10 and interfering. You never know. I believe it is Windows and not Mission Planner only or at all.

I tend to agree that it is Windows related and not a problem with the code in MP. That’s the primary reason I got this Windows laptop so I could try MP out on its native platform. When it works on Linux, but not on Windows, it indicates something is going on with Windows causing it to fault. But I don’t know what that would be.

On Linux I am using the open source version of .Net (mono) to run it. I wrote a little shell script to start it with a clickable desktop icon, so don’t have to start it at the command line. The gauges and buttons don’t display quite right on Linux, but everything functions correctly otherwise