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 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.
.\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 http://sourceforge.net/p/dfu-util/tickets/
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)
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.
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?
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.
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. 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.
EDIT:
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.
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.
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!
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.
