Error communicating with bootloader
-
Something worth noting is that when power is first applied, the LEDs do not flash in the normal pattern indicating that the board is ready to be flashed. This is the output of the bootloader update:
nsh> bl_update /fs/microsd/modalai_fc_v1_bl.bin
INFO [bl_update] image validated, erasing bootloader...
ERROR [bl_update] erase error at 0x8008000
INFO [bl_update] flashing...
INFO [bl_update] verifying...
INFO [bl_update] bootloader update complete -
HI @czarsimon what QGC version are you using? This is the second time I've heard of this now and is not something that is on my radar.
-
@modaltb I actually just updated to the latest version today in an attempt to remedy this: HEAD:f9ebc2720 2021-08-31. However, the version did not change between the time when everything was fine and when this problem started occurring. Do you think using an older version of QGC could be a fix?
-
I'm not sure yet, we've not changed the bootloader in over 2 years so I'm unclear what's causing this right now...
-
Hmm something different is definitely happening with different QGC versions, I just tried v4.0.11 and for a brief moment the firmware selection menu showed up but then disappeared and I got the same error but with different codes:
Error: Sync: Send Command: Invalid sync response: 0xfe 0x3c
-
I don't think this is a problem with QGC though, like I mentioned the LEDs don't even flash for the 5 seconds that the board is supposed to be waiting for new firmware during boot.
-
Hi @modaltb , I was doing some brainstorming on how to make the two boards we have with this problem work again, do you think getting a SEGGER J-Link and using that to flash the boards instead of QGC would work?
-
Hi Simon,
Yes, I have JLink files that you could use to flash it, but you need a particular wiring harness to get things going which might be problematic.
On a side note, we pulled a few random Flight Cores out of stock and didn't see the problem (e.g. we could upgrade via QGC (a May 2021 build was on the system we used). We recently moved from SEGGER JLink to an STLink so we can have a bunch on the production floor.
If the green LED isn't flashing on bootup while connected to USB, it's as though the bootloader is messed up...
We could re-flash at the factory here if needed too.
-
What would be the best setup to re-flash them in-house? Since it happened on two occasions already I'm not confident that it won't happen again so it would be nice to have a solution handy; can we use STLink on the boards we have?
If the bootloader is indeed messed up would flashing it using the instructions on the wiki with the help of an SD card fix it? I've tried that numerous times to no avail.
-
STLink can also work (I have files as well for that we can share). But, the failure mode is odd and I'm still confused, we have several hundred of these things out there by now and it's not common so I'm scratching my head.
The bootloader stays in bootloader mode only if it detects USB power, so I'm wondering if something else is happening hardware wise that is preventing the boot loader from knowing it's connected to USB.
It's a straight connection from the JST USB connector into the STM, there are some diodes on the path, but it's pretty straight forward.... I wonder if there's a hardware fault?
-
Indeed it was the diodes! I was able to fix one board by bridging the pads with some solder, the other one had the pads completely gone. Very strange, the flight cores are powered by the VOXL with the serial pins connected as well, but I don't see how that could cause hardware damage?
