X9D+2019 is not starting when bootloader flashing 2.8 RC1-3

[JimB40]

Is there an existing issue for this problem?

• [X] I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

When X9D+2019 radio is flashed with 2.8 RC1, RC2 or RC3 is dead afterward.

Expected Behavior

Should work.

Steps To Reproduce

1. Flash X9D+2019 with 2.8 RC1, RC2 or RC3 using bootloader

Version

Other (Please specify below)

Transmitter

FrSky X9D+2019

Anything else?

No response

[pfeerick]

Method of flashing?

It seems some of those transmitters are prone to bricking with a bootloader flash - have also seen some recent reports of it happening with OTX. I'm guessing you can still get into the bootloader?

DFU mode flash should work though.

[JimB40]

Bootloader. All other fw like 2.7 or 2.7.1 flashes ok. Did it several times. Yes bootloader is accesible all time

[JimB40]

Confirmed. It flashes via DFU. Stange 2.7, 2.7.1 & other firmwares flash via bootloader rock-solid every time. Double checked 5 or 6 different one now. Quite pity as that was 100% reliable & fast method up to now

[pfeerick]

Seems to change by the build... some 2.8 builds were fine, but others would just bork... What surprised me more was recently hearing some OTX builds appear to do it also (bootloader update was bricking, DFU was fine)... So far IIRC it seems the x9d family is more prone to it... I don't remember off the top of my head having issues with TX12, zorro, t-pro, etc... so hopefully, that will help narrow down the underlying culprit.

[raphaelcoeffic]

So we are talking about flashing the bootloader via the "SD manager", right?

[JimB40]

Nope. Flashing X9D2019 radio firmware EdgeTx 2.8 RCx using bootlader method I havent updated bootloader for quite a while I think its from ETX 2.6

[raphaelcoeffic]

Ah ok! So you mean this:

1. Start Radio into bootloader.
2. Copy the firmware file into the FIRMWARE directory on SD card.
3. Eject the drives
4. Select file in bootloader and flash

Is that correct?

[JimB40]

Exactly

[raphaelcoeffic]

Ok, then the only way to exclude such issues is probably to start adding some extra security with checksums on the files, read-back on the flash memory, etc.

not sure we can do this in a short time.

[raphaelcoeffic]

Or there is indeed something 100% messed up with these targets, which seems pretty strange, as the code is fairly generic. The MCU type is not specific either.

and, I won’t be able to test it myself. Ideally, when that happens, we would need to read back the firmware and check what has been really written to understand what happened.

[pfeerick]

How about I do a firmware flash via bootloader of a firmware that usually crashes this way... (i.e. 2.8.0-RC3), DFU read that back to file, and then do a DFU flash for comparison?

[raphaelcoeffic]

How about I do a firmware flash via bootloader of a firmware that usually crashes this way... (i.e. 2.8.0-RC3), DFU read that back to file, and then do a DFU flash for comparison?

No need to flash it back (except if it works :-D). In case it does not work either, I would compare both binaries: what should have been flashed, and what landed in FLASH memory.

[pfeerick]

This shouldn't be an issue as of 2.8.1 - an undetected firmware overflow. Neither my X9D+ or X9D+2019 have had bootloader firmware issues since the fixes were applied, and I was also able to update to 2.8.1 without issue (via bootloader). Please let us know if you still have any problems! :)