OK, arducopter-heli_with_bl.hex is now installed, but when I now try to connect it to MP I get the following error message:
When I connect the board to the laptop USB port, while pressing the button next to its USB port, I get the usual “ding-dong” sound confirming the device has been found. So what do I need to do to solve the mavlink issue, please?
once you have uploaded that bl firmware you do not need to hold the button just plug in usb. you no longer need to be in DFU mode
But if I don’t press the button I don’t get the “ding-dong”, and I get the same error message as before when trying to connect to MP.
I’ve tried also with QGC, and it doesn’t recognise that anything’s connected.
what does device manager show with it plugged in not holding the boot button. should be under com ports
As seen here you will get several different opinions on how to flash. I have found the best way is to use dfu-util and flash the bootloader only 1st. Bootloader files found here Bootloaders
After that you can use MP to flash the Ardupilot firmware.
Note: Follow the procedure here for With DFU
Flash bootloader dfu-util
BTW-One reference for this process is @andyp1per Build Blog for the 5" and 7" LR builds.
We’re getting somewhere: Using SMT32CubeProgrammer I reinstalled the _bl version of the Ardupilot 4.2.2 Matek H743 hex file. I realise now that when I did it earlier this afternoon it didn’t really do anything – this time it went through the delete files routine and then installed the new file.
MP still gives the same error message as before, and APMPlanner doesn’t detect any device.
QGC did detect it, and confirmed the board type and firmware correctly (Matek H743 mini, Ardupilot 4.2.2 heli), was able to reinstall the firmware, and was able to read the parameters, but in the Summary tab it gives an error message “QGroundControl does not currently support setup of your vehicle type. If your vehicle is already configured you can still fly”. The board is now showing solid red led, and flashing blue or green at various times, and my laptop now gives the “ding dong” sound when it’s plugged in without pressing the button. Previously it was only showing solid red.
To answer your question fuego, there’s no listing in Device Manager for com ports, but below is a screenshot of the USB portion of the screen. I don’t know which of those devices is the Matek board, but they’re all reported as working correctly when I click on them for details. The only other USB device connected to the laptop is a wireless mouse, so I don’t know why there’s 3 devices showing.
dxemr: Sorry, I didn’t see your latest post until just now because I was too busy composing my own reply to fuego’s post.
I can find the bootloaders using your link – presumably MatekH743_bl.hex is the one I would use. But I’m utterly confused by your DFU link. It implies that dfu_util is a program that will download a bootloader file, and says 0.11 is its current version, so I scroll down the index of releases to 0.11 and see six different files, none of which seem to be an executable program. Since I’ve got STM32CubeProgrammer running, would that be able to install the bootloader file instead?
But, as mentioned in my previous post, it looks like I’ve already got a bootloader installed, as well as Ardupilot 4.2.2 heli. The only problem is MP can’t connect to the Matek board. Is the bootloader in arducopter-heli_with_bl.hex the wrong one, or is MP missing some add-on that would allow it to connect?
Use this version for Windows “dfu-util-0.9-win64.zip” . It runs on a Command Line and as per the wiki you enter dfu-util -a 0 --dfuse-address 0x08000000 -D new-board-bootloader.bin -R of course substituting the bootloader file name you are using.
Thanks, I can find dfu-util-0.9-win64.zip in the list of dfu releases, but what do I do with it? I’ve downloaded it and unzipped it, and I get a folder with three “Application” files – dfu-prefix, dfu-suffix, and dfu-util. Trying to run dfu-util it appears that nothing happens other than the standard Windows message about do I want this program to change things. When I type the “dfu-util …” command into the command line (now called “Powershell” 
) I presume I replace the “new-board-bootloader.bin” bit of your command line example with the full path name for the .bin file I want to use?
P.S. I can’t find a wiki with instructions how to use dfu-util.
I once had a similar issue on a Matek H743 Mini. The board was defective. I replaced it, and everything worked as it should.
Try this;
Unzip the dfu-util files to a directory and put this unzipped BL file in the same directory:
MatekH743_bl.zip (18.8 KB)
Then from the Command prompt navigate to that directory. With the board in DFU mode enter this:
dfu-util -a 0 --dfuse-address 0x08000000 -D MatekH743_bl.hex -R
Thanks guys.
Yuri_Rage, I was beginning to think the same, since QGC can connect enough to confirm that the correct firmware is installed, but it and the other configurators can’t connect to do any configuring.
dkemxr, I’ll give that a go later today, before contacting the vendor about a replacement board.
Even though you can connect, I would try this: When Problems Arise — Copter documentation
Also I would try the latest beta of Mission Planner, just for kicks. It still doesn’t sound to me like the FC really is broken.
dkemxr, I think I got the dfu-util to work, but I had to include the full path name to do so, for “Windows PowerShell does not load commands from the current location by default”. The Matek board’s red led was on solid and the green led flashing slowly, but when I executed the dfu command, the green led started flashing very fast for a while before reverting to slow flash. I assumed that was the download completed, though there was no message on the PowerShell screen.
Anyway, I then fired up (and updated) MP, but the board wouldn’t connect using the “Connect” button. But when I went to the “Setup > Install Firmware” screen it successfully went through the installation of v4.2.2 copter. But still it wouldn’t connect when I went back to the Home screen and clicked on “Connect”. It gave the same error message as before, is there any significance in the fact is says there isn’t a mavlink device connected. I also got a Windows message saying the USB device I just connected was not recognised.
UnknownPilot; thanks for the suggestion. I’ve looked at that page and it seems to only suggest things that I’ve already tried.
“Device not recognized” can usually be remedied by going back to Zadig: https://zadig.akeo.ie and swapping the USB driver. But normally that’s needed before flashing only.
Can you see the board name + COM port in MP’s dropdown list?
“There isn’t a MAVLINK device connected” is odd, I normally simply get “Can’t connect to board” or so .
When I start MP it shows AUTO for COM port. Yesterday the dropdown list didn’t have any other options, but when I then plugged in the board just now, the drop-down list included “COM3 Ardupilot” which I selected but got “connection failed”. But then I checked the dropdown list again and saw “COM5 Ardupilot MAVLINk …” had been added (it definitely wasn’t there the first time), and when I selected that my board connected 
So, thank you to everyone for your help. I just hope it will now work the same on my workshop laptop. I’ll be back this afternoon if it doesn’t!
Edit: Just to let you know it’s now working on my workshop laptop. Thanks again
One lesson to be learned here is there are various methods of flashing firmware that have worked. Betaflight Configurator, INAV Configurator, STM32 Cube Programmer, etc. But in my recollection from the forum and direct experience using dfu-util to 1st flash the bootloader always works.
You’re right dkemxr. I think I flashed it (successfully according to the utilities I used) at least a couple of different ways before trying dfu-util. I’ll be using it first next time I need to flash Ardupilot to a non-Pix board.
dfu-util didn’t work for me today …
I just got a new Matek H743WING board and tried to load it with Arducopter Heli using the dfu-util method suggested by dxemxr back in August, which worked for me at the time. This time it appeared to work at the command line, but when I then went to MP to install Arducopter heli it found the board okay but showed the incorrect board name in the Install Firmware menu. It showed in the drop-down list two versions of the same board name (I don’t remeber or recognise what it was) plus an option to ‘ignore’.
So then I went to STM32Cube programmer utility, and it did the job – which for some reason I hadn’t been able to achieve last time. Going to MP to install the firmware I then got the correct MATEKH743 board name displayed, and installation progressed as normal.
I don’t know the technicalities of why one method should work one time an not another. Maybe (probably) user error, maybe different board achitecture? Anyway, for others in my position, just keep trying with the different methods outlined in this thread.
