Thread: IMPORTANT! If you want HELP in case of a bricked Garmin device, please follow this

Successful cross-flashing depends very much on the compatibility of the underlying hardware of the two devices. i.e. The board of the receiving device must be the same as the board in the hardware which is usually flashed with the donor firmware. In conventional Garmin devices this is determined by them having the same "PCB P/N" (read this thread to understand more fully: [Only registered and activated users can see links. ]).
(TLDR)
Points to note:

• Matching PCB P/Ns does not guarantee a successful conversion, however non-match of PCB P/Ns will result in failure and nearly always a bricked device. That may be a fatal bricking in the literal sense with no way to recover the device using any software method.
• Flashing a different fw will always fail if the basic types and region layouts of the original and donor firmwares/devices differ markedly. Flashing a different fw results in the region layout of the receiving device being changed to conform and if that's beyond the physical limits of the flash memory failure is certain. One way to experiment with relative safety (in conventional devices) is to use a 'hybrid' fw made up of the boot.bin (ramloader) of the receiving devices original fw combined with the other components from the donor fw and retain the device's HWID. Then if unsuccessful it's usually possible to flash back because the region layout is unchanged. A successful hybrid flash usually, but not always, means a complete flash will also work and with changed layout and changed HWID.
• Even if a complete conversion is technically successful there may be features in the donor fw that require the presence of certain other hardware which may be absent in the device being flashed, or vice versa, reliance on the fw having the ability to utilize hardware but such code is not written into the donor fw.

Obvious differences between the two firmwares in question:

• Fenix 3HR's fw although not encrypted has only one section consisting of the main system software "fw_all.bin" and has no "boot.bin" component (the ramloader). Usually (in conventional devices) that ramloader is flashed to a virtual region (decimal 12, hex 0C) and then that virtual region in turn flashes two physical regions, rgn 5 with the bootloader and rgn 43 with the X-loader and the actual boot process is started from there. It seems that the 3HR's ram is somehow self-loading and maybe contains a bootloader itself but that's conjecture, i really don't know how it boots up at all.
• Fenix 6SPro/ProSolar is firmly encrypted. Like a conventional fw (but unlike the 3HR's fw) it does have two sections however the first section doesn't have the conventional ramloader for rgn12, instead it has a bootloader for direct flashing to rgn 5. It may refuse to accept a non-encrypted fw flashed by RGN anyway.

Short version: Likely potential or even certain problems may result even in the event that the 3HR and 6SPro are indeed basically the same hardware, so you'll be proceeding at considerable risk.

@ Andy Waltson

Originally Posted by Andy Waltson

..........
Question 1 - I'm wondering whether encryption really matter? If Garmin introduced encrypted firmware and decryption at hardware level then it is just flashed as is.

Regardless that the device may or may not discriminate between fw of encrypted and decrytped states i'm quite sure the real problem lies in your device having a corrupt GUPDATE.GCD file on-board that so-far cannot be removed because Cure fw can't be made and loaded to re-enable Mass Storage Mode.

This is what i think is happening: Regardless of what BINs you flash directly to the relative regions using Updater.exe in preboot mode, the device on the next attempted boot cycle recognizes the GCD's presence and tries again to flash the relevant regions but stalls because it cannot properly load the GCD. Finding a way to remove or overwrite that GCD is the root of your problem imo.

Question 2 - Maybe the issue is related to RGN tool itself? Currently this cool app is the only way to flash firmware, since official WebUpdater/GarminExpress can't. I suppose they just replacing file at mass storage device without actual memory flush, so that's why they fail when actual mass storage device is not available.

RGN_Tool really doesn't deal directly with devices to flash anything. It only manipulates fw by converting GCDs to RGNs and vice versa, saving/loading BIN files and changing the fw's HWID etc.

GarminExpress and GarminConnect are both clearly unavailable to the device because they rely on MSM and wireless connectivity respectively. That only leaves preboot mode access which both Updater and WebUpdater can use to access devices. WebUpdater can also be run in command line, however that would require that you know the exact path to the on-board GCD to overwrite it with a healthy file and also pre-supposes that WU can access the actual internal memory in that way when a device is in preboot as it can for MSM. I simply don't know. Usually using preboot (aka Garmin mode in very old devices) WU accesses entire regions and although in modern devices the internal memory is also a region (in more conventional devices it's either rgn 48 or 83) i have no clue if that's the same for your fenix. Maybe you could overwrite the entire file system region with a copy that doesn't have the GCD file, that's if you can confirm that it exists as an actual region. GPSDaemon can dump regions of Garmin Mode devices and that's actually a type of "perpetual preboot", read [Only registered and activated users can see links. ] onwards in the GPSDaemon thread. The decimal regions 48 and 83 are hex 30 and 53 respectively (like RGN_Tool, GPSDaemon deals in hex numbers for regions). A successful file system dump will be a *.HEX file which can probably be re-named to *.BIN and opened in a program like PowerISO or an archiver like 7-zip, to allow you to remove the GCD and then repackage it to re-flash as a BIN file back to the correct region using Updater or maybe even WU as a command prompt. Pure conjecture of course.

Question 3 - Maybe RGN tool does not work properly with such latest GCD firmware. According to version history at README last supported Garmin device was Fenix 3 HR (released 5 years ago)
v0.94 - Support for fw_all.bin file in fenix3HR and D2Bravo
Is there any chance to reach tool's author for assistance?

Well it certainly can't deal properly with this encrypted firmware it seems. As for TurboCCC who's the author of RGN_Tool and other great custom programs, he's dropped out of sight completely and afaik anyone who's tried to contact him in recent years has been unsuccessful.

I'm so sorry Mate, i'm now at a dead-end here. I hope someone else can help you or you can find a way yourself to get rid of that GCD file, maybe as suggested to dump and re-flash the file system or some other method.


@carrywhite

Originally Posted by carrywhite

I tried to use the GarminCure3 tool and to follow the process described [Only registered and activated users can see links. ] I downloaded the file eTrex10_Webupdater__360.gcd and used it to complete the described process. When the Updater.exe was done, I got a message, that the Update of the firmware has been successful.

But now the device does not boot anymore. It can't enter pre-boot mode and the device is not recognized by PC anymore. When I turn it on, only the Garmin Text shows on the screen. I can't even turn it off anymore. To turn it off, I have to remove the battery.

It's not clear how far you went "to complete the described process". I'm thinking you only got as far as loading the Cure fw but if it was loaded and there's no hardware issues then you should have MSM available. Is that all you did and still no MSM? Did you try to re-format before loading Cure fw as i suggested? Also did you confirm the HWID before using the US/EU fw to make cure fw?

Garmin support said, the device can't be rescued anymore. Is that true? Is my device wasted now? Do you have any more ideas, on what I can do now ?

Garmin support is sometimes the best source of misinformation regarding bricked devices. It indeed might not be possible to recover it but they won't even try to help you. Answer my questions above and we'll see what can be done ongoing. Please give the exact sequence of steps and precise info of what you've done.