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

Ok maybe all isn't lost just yet in that case and there's some feint hope still.

Some things i'm just not fully understanding however ... you said in your first post that you'd re-formatted the device using RMPrepUSB which means at some point the device managed to be seen in MSM at least for a while. However, the first txt cmd in Update.txt should have resulted in Update.log reporting that it failed! That's because gupdate.gcd should not have been present, so it shouldn't have reported as successfully deleted. Seems that the format wasn't in fact properly completed and there may well be other files still there and so the possibility of one being corrupt remains. Are you certain that RMPrepUSB properly reported it finished the format earlier?

It's good that 41 dumped it's full region size. On the other hand, failing to write regions 14 and 127 using xrgn isn't great. No entry after 'reboot' is expected seeing that didn't happen.

Would you please post a copy of your 41.bin for examination. It's encrypted so if you open it in a hex reader yourself it'll appear to be all 'empty' FF bytes but i can examine it for any obvious damage. You can attach it directly to your post using the function in the advanced editor (use "Go Advanced" button) provided you compress it to a ZIP or RAR file first, or you can just upload it to a free hosting site like MegaNZ if you prefer and send me the link by Private Message.

I'm ok with pressing on with this if you are, even if it's just for educational purposes because i still have a few things to try if you're up for it.

Here is a 41.bin zip file. I wanted to be sure we are on the same wavelength with respect to formatting using RMPrepUSB. I am referring to formatting my 8gb plug-in memory card. I have never had access or seen the flash memory inside my Nuvi1350. I always format my 8gb memory card with a card reader and then plug it into the Nuvi (after adding the necessary boot files). I reformat between attempts just to be sure it is clean. Hope this makes sense.

That does make sense now, thanks.

This is OT but wouldn't bother taking time constantly fully formatting (aka "erasing") any flash memory such as USB sticks and media cards unless absolutely necessary as it writes zeros to all bits. Simply deleting unrequired data is usually enough, and a "Quick Format" in Windows simply marks the drive as fully available so both latter methods cause less wear and tear.... but it's minimal anyway.

I'll decrypt the 41.bin when i have a chance to check it then depending on that result we can carry on. Standby.

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.