Boot Pads are off :(

[Deepfreeze]

This is what it looks like when I try to flash. I have not pluged it in, normaly there is COM3 showing up on the upper left hand side.

[sandmen]

You should use the flash button on the esc32 page.

[Deepfreeze]

But where can I set the File I want to flash. On the ESC32 Tab when I try to klick in flash fw nothing happens.

[13brv3]

OK, I haven't done this in a while, so I had to go back and do it again just to make sure I wasn't telling you something incorrect. Mostly, I couldn't remember which version of the GCS I was using, and I find that I can't make it work on 1.2 or 1.3 versions. Those versions also won't read the ESC parameters.

The GCS version that works for me is 1.0.5. This is the only version that allows me to flash firmware, and read/write parameters to the ESC32, so I'd give that a try.

Cheers,
Rusty

[Max]

Flashing firmware works basically the same in all QGC versions. It uses stm32flash.exe by passing some command-line arguments. One can use stm32flash directly from the CLI and bypass QGC altogether.

The bottom line is that with an early fw version loaded on the ESC32, you need to short the boot pads before flashing. With later versions, you can first connect to the ESC via serial, put it into bootloader mode w/out shorting any jumpers, disconnect the serial, then flash.

QGC will just try to do the bootloader step for you. In < 1.3 it would try this only when used from the ESC32 tab "flash fw" button. To flash using boot jumper, you'd use the main flashing tab, as currently described in the ESC32 documentation. QGC 1.3 simply combines the two methods into the one flashing interface, getting rid of the "flash fw" button on ESC32 page. It first tests if the ESC32 is already in bootloader mode, and if not, it tries to connect via CLI and put it into bootloader mode via command. If that also fails, it will bail with a (hopefully) sensible error message.

The most common cause of problems is that the COM port is already opened by QGC or another program. stm32flash errors aren't always very informative, and "failed to get ACK" could mean a number of things, including that COM port is locked or the STM32 isn't in bootloader mode.

I hope that helps clarify things... it's really not that complicated and there's no reason to have 3 versions of QGC installed to manage any of this. Rusty, if you can't read/write params with QGC and compatible ESC32 fw versions (r14 through r21 are not compatible), please let us know the details in a new thread (or point me to it if I've missed it).

-Max

[13brv3]

OK, it seems my workshop machine isn't playing nice, so I started a thread here-
viewtopic.php?f=26&t=2483

Since the machine I was using isn't being normal, you should be suspicious of any of the comments I posted about flashing these ESCs.

Good luck,
Rusty

[Deepfreeze]

So now I am confused .

Can pls someone tell me what to do to flash a brand new ESC32 just soldered when the boot pads are off?

I tried to flash it with the current QGC but the red led is flashing over and over. I tried to shorten it like shown in the picture above. Red led is off but the message not in boot loader mode already appears on screen.

It would be nice if someone can provide a short list like:

connect ftdi to esc
power it up
open QGC
go to widged autoquad
select your fw hex file

I never tried to connect with putty or terminal stuff, so I need your help .

[13brv3]

FWIW, my workshop machine seems to have had some sort of port issue in XP, but now that it's working, I can confirm that everything works as Max explained (of course <g>). The latest version of GCS on the download page is 1.3.B2, and he's cleaned that up to take away the confusion of where to flash, so there's no longer a flash option under the ESC32. I'd suggest starting with that version just so we're all on the same page.

I'm guessing you have another ESC32? If so, you might try a different one just in case the first one has a problem.

Also, take a close look at the FTDI connector on the board. The pins are always too long for the pads that they sit on, and I usually clip them off enough to keep them from overhanging the pads. I'd look closely to see if maybe one of those overhanging pins is shorting to another trace, since that could easily explain your communications issue.

Worst case, maybe you can send it to someone to test. If you're in the US, I'd be happy to look at it, though you can probably find more qualified people

Cheers,
Rusty

[Deepfreeze]

[bn999]

Connect a serial cable and use the "bootloader" command from the CLI.