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

I think "Prepare Drive" function in RMPrep is the same as Windows (so called) "Quick Format" where only the card's header is rewritten to mark all space as free and available for writing new data, then any existing data is overwritten eventually. So yes, that's not a full format.

I've looked at your nonvol BIN file. It appears normal when decrypted however that's not to say definitely there's no 'poisoned' data in there, just means there's no obvious corruption.

Let's see if we can dump copies of the firmware regions even though they couldn't be overwritten with the ''xrgn" cmds. Made a fresh copy of Update.txt and open it in Notepad to edit. Make the following changes:
Remove:
del,0:/.System/gupdate.gcd
rrgn,41,1:/41.bin

Change:
xrgn,14,1:/14.bin
xrgn,127,1:/127.bin
reboot

To:
rrgn,14,1:/14.bin
rrgn,127,1:/127.bin
reboot

Before saving it back onto the card, check there's no extraneous carriage returns at start or finish and no spaces at line ends.

Remove 14.bin and 127 bin from the card. It should only contain Garmin\Updater\0972 with the amended update.txt (and optionally update.log).

Follow the previous flashing procedure using Updater.exe in preboot. If it works you should get 2 new files in the card's root, 14.bin and 127.bin, if so please zip or rar them and upload. If it fails post the latest content of update.log please.

@Bellmac
The function "rrgn" (copy region) dumps the entire space that's allocated to it in the region layout, that's including empty available space along with already written data. The unused space simply shows as empty FF's at the end of the file when a dumped BIN is viewed in a hex reader. If you were to remove all the extraneous FF bytes beyond the checksum the resultant saved file should then exactly match the bin file from the firmware RGN or GCD.

The firmware regions of your 1350 are not encrypted like the nonvol region. Regions 14 & 127, as most other regions of the flash memory (other than protected ones like region 5 for example) can be dumped fully and plainly read and manipulated in a hex editor. In fact a suitably modified fw file is accepted and used by a 1xxx device with a correct checksum written at the end of its usable data. Region 41 is quite different - even if first decrypted, its data modified, the checksum corrected, then re-encrypted to XOR before flashing back to the device, it will be partially overwritten appropriately by the device itself on the next successful boot cycle. Therefore, making any changes is pointless. The only time writing nonvol back to the device is worthwhile is when you have a 'clean' unadulterated backup from the past and you know or suspect that the region presently has poisoned data.

So you don't need to upload the 14 & 127 dumped files as you did with 41, you can check them yourself. Simply open them and the corresponding original BIN from the firmware in a hex editor (Hex Compare as shown below is perfect as you can open 2 files at once then use "Search > Go To First Difference"). They should be the same data, other than a whole lot of FFs trailing behind the checksum in the dumped file, i.e.: The original 14.bin from the fw is exactly 9,340,160 bytes (8.907470703125 MiB or 9121.25 KiB - that's mebibytes and kibibytes which uses binary factor 1024, not decimal 1000 used by MB / KB - megabyte / kilobyte). However as said, the dumped region bin file is much larger only due to the empty FFs trailing beyond the checksum - which is E7 in V6.30 fw's 14.bin (fw_all.bin). Removing all FFs behind the checksum in the dumped file (it is 16,777,216 bytes/16MiB/16384KiB) should result in identical data files with size of 9,340,160 bytes. Like mine, your dumped file comparison should have the first difference as the FF behind checksum E7. If not the same right up to there, it indicates corruption in region 14.

Spoiler: Hex Image

[Only registered and activated users can see links. ]

BTW, Windows rounds up and still stubbornly uses the (original and technically correct) binary form with factor 1024. For instance, 9121.25 MiB (9,340,160 bytes) is shown in Explorer as "9122 MB".

Please either report on your own comparisons of the dumped BINs or upload them so i can inspect them. Once that's established one way or the other, we can try other things. Provided this isn't a hardware problem (that's still very much on the cards), I honestly do think that there's maybe some serious corruption in either 14, 127 or 41 so if we rule out fw it only leaves nonvol as the villain. That still wouldn't fully explain why 14 & 127 can be dumped using "xrgn" but not overwritten with "rrgn" ... although a poisoned nonvol can do weird things. If we have to eventually erase 41 fully and the problems persist it only leaves hardware as the problem, as in a failing flash.

@VadimK
Good lateral thinking there. However it's not the answer, provided the file to be written to a region is smaller than the total region size it will succeed. It's actually the other way around where a file larger than the region's space may fail, even if only marginally bigger i.e. region 14's available space is 16,777,216 bytes and we try to flash a file of 16,777,217 size to it it'll likely fail but 16,777,216 or less will succeed.

BTW, you can use Hex Compare for 15 days free without obligation to purchase.

Code:

Please Login or Register to see the links

Just click the Download button rather than the Order button. I'm still happy to do the comparison for you if you want, just upload the BINs, preferably compressed, to MegaNZ. You can make a free basic account there to upload:

Code:

Please Login or Register to see the links

But i understand if it all just seems a bit overwhelming and not worth it. Anyway, in truth the combined value of its separate working/good parts are likely worth more than the value of the complete device working.

Just let me know because if you really don't want to press on i'll move our posts to a dedicated discussion thread to finalize things.