Matek H743-Mini DOA? [solved - defective board]

I am attempting to configure a Matek H743-Mini with Copter stable. Previously, I have successfully configured an H743-Wing v2 for use with Rover by following these instructions.

It appears that I can erase and flash the board with STM32CubeProgrammer, but it does not show up as a serial device upon subsequent connection on the USB port.

I attempted to follow the instructions listed here but receive an error when attempting to flash the “all zeros” file.

Any suggestions before I return/replace the hardware?

I just received the slim version and the 1st thing I did was flash the bootloader using Df-util. Then used Mission Planner to flash copter.

1 Like

I have the slim version. After flashing with the bootloader FW version I have not had any issues. Flashing with STM32CubeProgrammer I used the arducopter_with_bl.hex file.

1 Like

Output from dfu-util:

.\dfu-util -a 0 -S 200364500000 --dfuse-address 0x08000000 -D '..\MatekH743_bl.hex'
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to

Warning: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0483:df11
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash   "
Downloading element to address = 0x08000000, size = 48052
Erase           [=========================] 100%        48052 bytes
Erase    done.
Download        [=========================] 100%        48052 bytes
Download done.
File downloaded successfully

Plugging the board back into the USB port results in no device detection after this step.

Flashed my H743-Wing v2 with MP on the same computer yesterday, so I shouldn’t have any driver issues.

That file MatekH743_bl.hex looks to be the bootloader only file that is used by waf for building the ardu_zzz_bl.hex files. (Found in Ardupilot/Tools/bootloaders)

Try flashing using STMCube or your dfu-util program with this file instead:

I dont have the mini version of that board but do have the WingV2.

1 Like

I have actually tried several times to load just the bootloader as well as the full firmware using the .hex that includes the bootloader using STMCube. I will try again with dfu-util, but I’m thinking I may have a faulty board.

Just for grins, I downloaded Betaflight Configurator and tried uploading their firmware - received an error at the end of the process and was unable to connect outside of DFU mode.

Hmmm that is annoying…

My only other thought is resorting to a special hwdef for you (aka switch the serial port and use a serial to TTL converter). Or attaching to a debugger but I figure that is likely not worth the effort for you.

If you took hi-res photos we could try to see if there are any connection issues?

Other than that I’m out of ideas ATM.

1 Like

I’m hesitant to connect anything because all of the transmit pins are soldered connections, and I’d like to keep the option of a potential refund.

dfu-util fails to flash the full firmware file. STM32Cube reports success, but the subsequent, expected USB serial device connection is non-existent, and the status LEDs blink during what I assume is bootloader activity, then all 3 go steady on. I’d expect some blinking/flashing (like on the Wing) rather than just 3 steady lights.

I did order a replacement already, expecting that I will likely have to use a different board.

On the plus side, and entirely unrelated, I got a DJI digital FPV system running independent of the flight controller (for now), and it’s amazing! So the day wasn’t wasted.

@hendjosh - updated with the best pics I can get:

Thinking about it further if you can correctly program the board I really doubt a hardware issue specific to just the usb.

You could check along with the “Full Chip” option you can check the “Verify programming” option too.

Like you said it is probably stuck in the bootloader. The question is why… and the only way to get into that is through the debugger.

I totally understand your soldering issue… that is why I have a set of these cool pogo pins. :slight_smile: Saleae Cart

On the DJI FPV stuff I made the mistake of getting a caddix camera with my holybro cinewoop not understanding I’d be stuck with the DJI system. And haven’t decided how to get the video from it to a tablet etc.

Since I made you take photos… here are the USB data pins (i think) in rectangles and one weird thing. I doubt it is your issue. There could be other hardware things but I’d need photos that are full resolutions to try and see discuss likes to downgrade things.

I will continue to beat my skull against the wall until either a new board arrives and behaves as expected, or I get this working!

If you think it’s a worthy endeavor to debug, I’m not opposed to sinking the cost of this board in the interest of learning. But I must admit - I’m not well versed in STM32 debugging. I have a reasonable handle on the build environment and library structure of ArduPilot, but not so much a grasp of STM32 programming and debugging at a lower level.

The pogo pins are a great toolbox addition. I really should consider getting some.

As for the Caddx and anything other than DJI receivers…I got nothin’! This is actually a Cinewhoop build - a Shen Terraplane, to be specific. I want to explore small quad params as well as indoor/non-GPS flying with ArduPilot.


One last try tonight with STM32Cube - verification fails:

Error: Data mismatch found at address  0x08040000 (byte = 0x00 instead of 0xF2)
Error: Download verification failed

Without knowing more, it seems as if the erase completes, but the write has failed.

A closer inspection of the “weird thing” above the word “MINI” shows it was just a piece of lint. The adjacent capacitor appears soldered well.

Perhaps you have tried this many times already? Using DF-Util
dfu-util -a 0 --dfuse-address 0x08000000 -D MatekH743_bl.bin -R

Yes, I’ve tried with and without the -R switch. Still no dice!

Man, I have struggled at times to flash boards but it seems you have run down all options! Perhaps you are right and it’s a hardware fault. I suppose you will know soon with the 2nd board.

1 Like

If your verification is failing that doesn’t sound good…

Here is what it looks like when I use the STM32CubeProgrammer for weird problems (I usually don’t verify for normal flashing.)

1 Like

That’s exactly what I had set when it failed verification.

I’m writing it off for now. Will update the topic when I receive the replacement.

1 Like

The new board arrived today, and I can report first time success flashing the full firmware + bootloader using STM32CubeProgrammer.

Thanks to all of you for the suggestions - I learned about dfu-util along the way.

I’ll contact the supplier for a refund on the other board…if that’s even an option!

On a related but maybe somewhat amusing note, Ultimaker Cura (3D printing software) will appropriate MAVLink serial ports if it’s open in the background, which will cause failures to connect. That was NOT the root cause earlier this week - I was just multitasking today and discovered that I shouldn’t do too many things at once!

1 Like

Out of curiosity is this the newer V1.5 version of that board with the ICM42605?

Appears to be the older one with the ICM20602 (according to the original packaging). I can’t quite visually decipher which component corresponds to that particular IMU.

The MPU6000 is clearly marked, but the other chips are more cryptic in their labeling.

OK, curious because for some applications it’s suggested to disable the ICM20602 (Andy’s 7" build blog) and I wonder if the ICM42605 would perform any better. The new Slim version I have also has the ICM20602.