Quote Originally Posted by Andy Waltson View Post
.............
GarminExpress - does not see the watch, so it's not possible to update it in usual manner. WebUpdater fails as well, probably because watch memory is not visible at OS.
GE uses Mass Storage Mode to access devices. WU can use both preboot mode and MSM. In preboot mode the device will be visible in Windows Device Manager but not in Windows (File) Explorer.

GarminCure cannot convert it:

Processing D:\Fenix6SPro_6SProSolar_1660.gcd
This is a GCD file.
No patchable HWIDs detected
Processing FAILED
This is not a good sign. It may be more than just a non-typical firmware, see more below about this.

So I've tried open GCD using RGN_Tool_V094:
........
However there are no detected HWID and SW version (Question #1 - is it expected?).
When I've tried to convert it as is, I've received this warning: ........
Not showing a HWID in RGN_Tool is common with some modern Garmin device firmwares, however not showing the version is unexpected. Again, weird fw because also what is not typical is directly flashing region 5 with the bootloader. Usually in a more typical fw it's done indirectly by the (so-called) boot.bin (slight misnomer as really it's the ramloader and not the bootloader itself exclusively) being flashed to a virtual region 12 (hex 0C) and rgn12 then in turn flashes the bootloader to rgn5 and the x-loader to rgn43, both of which are actual physical regions of the flash. That's why RGN_Tool gives the message "..... I hope you know what you are doing!" because it's expecting the first section to contain "boot.bin" (Region 12/hex 0C, Section 0800) and not "fw_0505.bin" (Region 5, Section 0505). In typical devices rgn5 cannot even be flashed directly using any external method because it's protected against that and only can be written to by rgn12. If your fenix has rgn5 protected against external flashing then any attempt to flash an RGN will fail and that's potentially a huge problem.

After opening converted RGN, it looks the same: .........
Yes but they only look the same in RGN_Tool because all it shows on the GUI are the separate fw components. An RGN file and a GCD file of the same fw differ only in that there's a header added to the GCD file. Think of a GCD as a 'smart' file, kind of like a type of self-extracting EXE file. It's placed on the device and flashes the required regions from there quite independently but of course it requires the device to have fully booted for the GCD to be initiated. An RGN file can be considered as 'dumb', it doesn't do anything by itself and requires Updater.exe to flash its components directly to the appropriate regions of the device.

Question #2 - is it safe to try and upload it using Updater.exe into device?
Yes it is safe, that is it's safe provided the RGN file is not corrupt and it's named correctly and is suitable for the device. Correct 'safe' naming is XXXX01000xxx.RGN where XXXX is the firmware's HWID and xxx is the SW version without the decimal (e.g. 328801000160.RGN). Updater.exe on reading that format will first query the device and compare the fw's HWID with the device's reported HWID. If there is a mismatch it will stall without flashing, giving the message "No updates are available ...". Any other naming (e.g. OUT.RGN, Fenix6SPro_6SProSolar_1660.RGN or even altering the middle numerals 01000 such as 32880100160.RGN) will let Updater skip the HWID check and force the flash with potentially devastating results if the HWID of fw and device doesn't match.

Question #3 - is there any hope to resolve this headache introduced by Garmin?

Hope somebody will find time to answer...
I haven't checked in detail the forum link you posted however if this problem is both common and due to Garmin issuing a corrupt fw then they may be prepared to replace the watch regardless of it being out of warranty. I think it may be worth you contacting them before attempting a software repair yourself.

The problem for you is that to remove the (likely faulty) GUPDATE.GCD from the device's internal memory you will need to load cure firmware to re-enable Mass Storage Mode and Cure3 isn't cutting it by your experience (again, probably it doesn't like the unusual layout of it because of fw_0505.bin being where boot.bin should be). Flashing a good original fw as RGN via Updater may not be sufficient although that's worth a try for sure. If after flashing an RGN the corrupt GCD on-board continues to prevent it to boot then the only answer would be to manually make cure fw yourself (see this thread: [Only registered and activated users can see links. ]). As it's highly likely that it's the GUPDATE.GCD loaded by GarminExpress causing the problem, you could try only changing GCD to XCD in a hex editor initially.

I hope this at least helps you understand the likely problem and a possible solution to try if Garmin won't take responsibility for GE loading a bad GCD file. Post again if you think we can help further or you need some clarification. Sorry that this reply is not only wordy but a bit negative, however i'm happy to keep trying to help you even if Garmin won't. Good luck.