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

When I search the ExpressDetaled.log files on my W11 PC using "nuvi13xxand14xxseries" as the search term, I get ""https://download.garmin.com/software/nuvi13xxand14xxseries_GCDFile__630.gcd"

I used to run updates from an older W10 PC. I took a look in those log files and this search term produced nothing. However, I have a number of Garmin devices, so I am not sure any Nuvi1350 updates are reflected in those log files.

As you can see, I have little understanding of how Garmin creates these log files and whether they are overwritten with each attempted device update.

I did a search of the ExpressDetailedLog files on my current W11 PC using "nuvi13xxand14xxseries" as the search term and always found "https://download.garmin.com/software/nuvi13xxand14xxseries_GCDFile__630.gcd"

I previously did updates of this Nuvi1350 and other Garmin devices on an older W10 PC and searched those log files, but there was no result on the above search term. I'm not sure how Garmin creates and deletes these log files so those files may be the result of an update of another device.

It's the files named Express.log or Express_**.log which disclose the HWID as shown in the image in my last post above yours.

You should have at least one so named, they'd be listed above your "ExpressDetailed" LOG files. These are my recent GE LOG files:

Spoiler: click

[Only registered and activated users can see links. ]

There's always the possibility that although you've found "nuvi13xxand14xxseries_GCDFile__630.gcd" file in the ExpressDetailed log file, and clearly it's the non-MTK firmware by its naming and therefore HWID 0972, that the log may actually be for your other 13xx device. It's absolutely imperative that the original HWID is identified so look again in the Express folder for the files named only Express/Express_**.log and check it/them. Those files will also list the device's Unit ID (UID) in several places, so as an additional check search for "Getting sync upload settings for device" which will show you the first instance of the device's UID in the file, like this for my nuvi 55:

Spoiler: click

[Only registered and activated users can see links. ]

Check that UID against the UID that you found in G7ToWin after the bricking:

Spoiler: click

[Only registered and activated users can see links. ]

Then there'll be no doubt which of your 13xx devices was last updated. It also means if the UID in the log file matches with G7ToWin, which has shown the present HWID as 0972, but in fact the Express log actually shows you'd used nuvi13xxand14xxseries_GCDFile-MTK__630.gcd firmware for 1104, that a cross-flash has somehow occurred when using cure fw.

There are entirely different recovery procedures to attempt depending on whether it's been cross-flashed or not you see. In fact it will likely be far more feasible to recover if it's been cross-flashed because otherwise the original symptoms are probably due to a hardware failure rather than a corrupt file. That's given the inability of Updater.exe to completely finish writing to at least one flash region.

Ok, it seems 100% certain it's a non-MTK then. I'll make a kit to try force-flashing the regions using a microSD so get a CLEAN small card of no more than 32GB ready, formatted in FAT32. Other projects take precedence ATM so watch this thread in several hours from now.

EDIT: Butters had in fact made the required kit some time ago and posted in [Only registered and activated users can see links. ] here for ISG to use on a malfunctioning nuvi 1310 which he'd reported in Post #270 could not be flashed normally with Updater.exe. It was returning the same error you got (see his Post #272 also in this thread) and in his case the 1310 had indeed been wrongly flashed with fw for nuvi 12xx HWID 0971 (it was that same error screen you reported which had made me highly suspect your device may have been cross-flashed too). It his case the 1310 wasn't recoverable using software means and although in your case i'm now convinced the 1350 hasn't been cross-flashed, that's just unfortunately pointing to a higher possibility that it's had a hardware failure, simply because that can cause the exact same Updater error.

So to explain fully about this flash kit using Updater and a media card and why we need to try this method:

A device that is unable to get at least as far as displaying "Loading Maps" on the splash screen is unable to read a media card because it doesn't look for a card until after loading those essential files. Your device isn't loading files of course, and even though it can attain preboot that too occurs before the device looks for a card. However, the modified ramloader (aka boot.bin) in the RGN executed by Updater.exe forces the device to read an inserted media card much earlier, while it's in preboot mode. Provided the device's flash regions aren't physically damaged, then the two firmware BIN files on the card will be forcibly flashed to the appropriate regions (14 & 127) allowing it to boot normally. I note that you initially reported being able to reformat it using RMPrepUSB so the visible flash region in rgn 48 will be empty and that's ok because 1xxx devices are capable of booting when empty. Therefore it's not 'soft-bricked' by a corrupt file even if that's what did actually cause the original failure while in use. There should also be a copy made of it's rgn 41 (the non-volitile memory), and if a gupdate.gcd was present that is deleted - but as your file system is empty that command will fail which is of no consequence.

So download the file "SD Flash - Patched boot RGN.zip" from Post #286 and extract it to find a folder "Contents For Card" and two files, Updater.exe and 097201000630.rgn. Open the "Contents For Card" folder and copy the Garmin folder and 2 BIN files directly to the root of the clean small microSD then insert the card into the 1350 ensuring it's completely OFF. Drag the RGN onto Updater.exe to open it, put the device into preboot and start Updater. If the flash initiates properly it will take a while so let it run until it hopefully re-boots itself. Good luck.

I am assuming that while using updater to flash the rgn file I need to press the top left of the screen before inserting the USB cabke. At what point am I able to to take my finger off the top left of the screen? Approximately how long will I need to be holding it?

Update:

So, after a couple of practice sessions, I ended up taking my finger off the left upper corner after seeing a successful flash of the rgn file in the boot patch using updater.exe. This is what happens after that (done this a couple of times, each time starting with a freshly formatted memory card):
- "Software Loading" appears at top of screen
- "Loader" appears at top of screen
- "Software Loading" appears at top of screen
- "Loader" appears at top of screen
- Green horizontal line at bottom of screen

After that the Garmin logo appears for a minute or so followed briefly by a blank screen. This process seems to continue indefinitely.

During this period, the Garmin device (i.e., its 8gb memory chip) is seen as a USB device in my PC, but I do not see any additional files. The first time I did this exercise, I saw a 41.bin file in the root, but after redoing this process, it does not appear.

If I turn off the 1350 and plug it in, it does not appear as a USB device in my PC and I basically have to start over.

If I try to use Garmin Express or WebUpdater, neither program detects this device.

Not sure how long to let this Logo followed by Blank Screen activity continue. I will let it go for a half hour more, but it does not appear to be moving forward in any way. It looks like there was some progress in getting it into file reading mode, but not much more.

Second Update:

Let it run for about an hour, but nothing else happened. After turning if off and restarting with a PC cable, it would not reconnect to the PC or respond to Garmin Express or WebUpdater. And the PC would not recognize it. I took a look an the memory card and saw the 41.bin file had been added. The update.log file in the 0972 folder indicated that both the device ID and the HWID werre 3827336719. That is the device ID. I would have thought the HWID should be shown as 0972. Perhaps that would eventually change if the new fllashing worked correctly.

You can remove the pressure from the LH top corner at any time after a loading/loader message appears on the device or just keep holding until Updater reports the flash results. Once an exchange of data starts between Updater and the device, preboot is locked and remains so while Updater is still communicating with the device.

A damaged flash memory is almost certainly now confirmed. It may fail completely at any time and in fact it's more likely to do that while being stressed during flashing attempts. You can of course continue in trying to recover it using the modified boot RGN but i'd just give up now as i really think there's very little chance of success now given those latest symptoms and you're clearly aware that a looping shift between the logo and white screen is not the required behaviour. Following the very first flashing attempt it should have fully re-booted after showing the logo splash screen where the copyright info usually appears. Sorry man, seems like "He's dead Jim". You can strip all usable parts like screen, battery, bezel/case and even un-sweat the USB socket and power switch from the board. They'll bring some $$ on ebay probably. The rest of the PCB has only junk recycle value. It's not feasible to replace the flash memory even if you had free access to the re-programming equipment required.

Interesting that it got so far as to create a 41.bin at least once. Did you keep a copy of it or note the size of the file? (It should be 4096 KiB in a healthy 1xxx but may copy as 0 in a malfunction device).

Out of further interest, did you notice if a file named "update.log" and/or "last_id.bin" was created in the 0972 folder at any time? (Between flashing attempts it's only necessary to remove last_id.bin, if present, so that the card's again recognised... but re-formatting does that of course).

EDIT: Just saw your 2nd update made several minutes back. The 'double-up' of HWID with UID is normal. I can't explain why that happens and what you said about expecting HWID to show 0972 is sensible. The fact that it creates the LOG file is telling me that the modified boot RGN works properly in Updater. Please post the contents of update.log file.

The 41.bin file is 4,096KB.

Update.log file:
nüvi 13xx Series Software Version 6.30, UID: 3827336719, HWID: 3827336719
------------------------------------------------------------------------------
Parsing "del,0:/.System/gupdate.gcd"
Success
Parsing "rrgn,41,1:/41.bin"
Success
Parsing "xrgn,14,1:/14.bin"
Error
Parsing "xrgn,127,1:/127.bin"
Error
Parsing "reboot"

Update.txt file:
del,0:/.System/gupdate.gcd
rrgn,41,1:/41.bin
xrgn,14,1:/14.bin
xrgn,127,1:/127.bin
reboot

I may try one more time making sure I press the upper left screen until after the first loader message appears (probably a waste of time).

Update

Tried it again and pressed the screen until I got the horizontal green line. Made no difference. However, this time, it did not appear as a USB drive in my PC.

I failed to answer an earlier question. There is in fact a "last_id.bin" file in the 0972 folder, which was also created in prior attempts.

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.