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

Some bricked devices do indeed reboot spontaneously when forced off by holding the power button and with them preboot can only be attained during that brief couple of seconds when it's actually OFF. Others thankfully remain in the fully-off state rather than boot-cycle. Devices that (a) boot-cycle; and (b) are tricky to get into preboot; and (c) remain in preboot for a very short time do make the user's workload very high. Your DS50 was all 3, so the luck, timing and skills levels required for success in flashing via Updater.exe are similar to getting a good outcome while juggling two live monkeys and a running chainsaw in one hand while tapdancing and eating a full bowl of runny custard with the other. So good work you!

Seeing you've reformatted it, you may need to add a base map because GarminExpress won't supply that like other map entitlements. The one from your backup should be ok to use because never have i had one of those get corrupted like detail maps easily do. It'll be an older one in of your backup or just get the latest version 6 from here: [Only registered and activated users can see links. ]. It must be named gmapbmap.img and placed only in .System folder to work however the version isn't too important.

@Maldonis
It may be that the device has a failing flash chip causing the bootlooping. If so then it's not recoverable by software means. While it's possible with the right kit and skills to do so, it's just not economically viable to replace and reprogram the chip.

However, it's also possible that the dezl 580 is one of the Garmin devices with cannot boot if the file system is completely empty. While most can boot empty (but of course not navigate or even show a map), some devices require at the very least an empty Garmin folder created in the root of the internal memory before they can completely boot, and some others require actual files onboard. Read about that in initial post in Kunix's Cure3 thread: [Only registered and activated users can see links. ]. Just be sure you don't copy from a recent backup any files that may have caused it to bootloop initially.

The device 'extracts' (or executes if you like) a GUPDATE.GCD from the (normally hidden) .System folder of the internal memory. In some outdoor devices the file is then automatically deleted but not in automotive devices.

It is possible to start GUPDATE.GCD from a Garmin root folder of the card. In a heathy device it will be read at the end of the normal boot cycle, and if the device determines the firmware in the GCD is a later version than is presently loaded it will flash it from there. The process is the very much same as if the GCD is in the internal memory which also requires that the device can boot. Note the use of 'heathy' and 'normal'.

It's also possible to write individual firmware BIN files from the card directly to the relevant regions of the flash memory but it's not possible to initiate (i.e. run) firmware directly from the card to start the device as you ask. Certainly some map IMG files and some other files such as points of interest GPI files can be used from the card. Even the initiating of BIN file to flash them from the card requires the device to be able to boot almost fully (usually just after the point in the boot cycle when maps would be loaded) to even examine the card. That process requires the system software (aka firmware) in region 14 to initiate enough to in turn initiate from SD the boot.bin renamed as ldr.bin (i.e. the ramloader). It's also possible to directly initiate flashing of firmware BINs from the SD in preboot using a modified boot.bin as an RGN file.

Regardless, i don't think such processes are helpful in your case because you can access preboot normally and appears to successfully flash the original fw that way although it then will boot-loop still. It flashes the Cure fw to allow MSM however but Cure fw doesn't fully boot the device, it intentionally stalls the boot-cycle before essential operating files are loaded. Therefore if it still boot-loops when empty or when 'known-good' folders and files are on-board the problem's elsewhere and most likely of a hardware nature. You can read about flashing from SD here: [Only registered and activated users can see links. ]. Info about modding ldr.bin in [Only registered and activated users can see links. ]. Try it if you want but if it doesn't work then a hardware fault is confirmed absolutely, sorry.

Originally Posted by HolycheeseNL

..............
1) Bricked device MODEL, Firmware version, HWID.
GPSMAP 62st, 4.80 (although self test shows 7.20 after trying flash, Updater still shows 4.80), 1113

It's possible that inconsistency of version # is due to a partially completed flash using V7.20 while the device had V4.80 onboard.

2) Why and how the device got bricked.
It started when someone downloaded maps from somewhere. After this point the device started to have trouble starting. Sometimes it worked for a while and then crashed. Now it seems to never pass 'loading waypoints, tracks and routes..'

That boot-freeze is usually indicative of a device that cannot load some file/s needed for normal operation due to those file/s being corrupt or incomplete. Certainly *.img and *.gpi files are commonly the cause of such a 'soft-bricking', if indeed it is bricked whether with or without a coincidental hardware problem.

Since this is a second hand unit it might be a previously existing hardware problem that happened to coincide with the uploading of new maps.

Maybe that's correct. In fact likely it has an intermittent hardware fault rather than solely a consistent soft bricking, and it could well be both as you mused. Perhaps it has a failing flash chip or a dodgy USB connection which is "making and breaking" and so it sometimes works long enough to only partially complete flashing or boot-loading tasks. But if it ALWAYS sticks on the same point in the boot cycle that's likely caused by at least one problem file. As said, there's always the chance it has both problems where the hardware fault manifested itself while it was being updated with maps or when the device was attempting to self-create a route or similar file in the memory and therefore the hardware fault was there before the bricking and in fact caused the latter.

3) Symptoms: what's wrong in your device?
It never passes loading waypoints during startup.
It is recognized but any communication with the device fails.
for example. Flashing can start but fails.
Calling for the HWID I can see the firmware version, HWID, but device ID shows 0. I also get an error "USB Error: WaitComplete: Error waiting for overlapped I/O"
Opening device properties in windows, opening device manager etc is all very very slow or never responding.

Such communication faults and connection inconsistencies and some of the others mentioned later in your post are unfortunately symptomatic of an intermittent hardware problem.

4) Does your pc sees your device ?
Not when normally connecting and starting.
The device is recognized in preboot and Mass storage mode
Garmin express never recognizes it.
WebUpdater only in preboot mode.
RMPrep only in Mass Storage
Basecamp never (not sure)
g7towin only in preboot

GarminExpress only connects in Mass Storage Mode and reads the device's Unit ID to determine if it can be updated. If the device has lost it's UID (yours shows "0" you said) then it won't even recognise it. It doesn't connect to devices which are in preboot or 'Garmin mode', only in MSM.
WebUpdater can see devices in both MSM and Garmin mode/preboot mode. Updater.exe of course only works for devices in Garmin mode/preboot.
PMPrepUSB is useful only in MSM, it can't see devices in preboot just like Windows Explorer, however G7ToWin is the reverse and only works for preboot.

5) List all the procedures you already tried to unbrick it and their results and errors messages obtained.
-I've tried webupdater in preboot mode. Error message: 'update is damaged' (sorry not sure on the exacte message, this is translated), when trying again it shows device is not responding.
-I've tried GarminCure, both Cure and Original > Updater. it instantly goes to 100%. After a while it shows a generic error: 'There is a problem with this Garmin Application'. The error messages doesn't look important. The device stays recognizable. Upon trying flash again it says the version is the same, yes, utility disappears after a few seconds.
-I've tried formatting it, but as soon as the device enters mass storage mode the utility is 'not responding', same goes for explorer in general if I try to open the garmin's storage.
-Master reset, freezes after pressing 'yes', shuts off after 10s or so.
-Self test freezes and shuts off after 25s or so. RAM passes but ROM is still at WAIT.

I suspect there is either something with ROM or I/O. In that case, should I blast it with a Hot air rework station?

Yes i also strongly suspect that's the case and it's also the root-cause of any software bricking. You can try re-flowing the connections of the USB socket to the MO. I use lots of flux, a fine tip iron and leaded-solder (if you can get it it's better than the EU mandated stuff), also you must reinforce the socket's mounts because it's weak mounts from the factory that cause the soldered connections to fail. I prefer to recommend solder re-flowing over hot air but you can try that if you're experienced. Of course you still need to beef-up the mounts. If it is actually a failing flash chip it's not so easy. You'd need to source a compatible BGA chip and re-program it after installation (reballing will be required for that). The process of unsweating and reballing isn't physically difficult but needs some skills and is harder than repairing the USB so do the socket reflow first anyway. In particular reprogramming the chip is a huge problem for casual users even with some background knowledge, and the equipment to do it isn't common anyway. Generally not worth it even if you can get a suitable chip replacement.

...............
8) Write down if you already read or tried GarminCure3 tool - the new way to create cure firmwares for Garmin devices
How to unbrick a nüvi - step by step guide
Tried

Was MSM only available when you tried with Cure firmware loaded, or does Updater stall every time and you've not been able to load any firmware, cure or original? If it does fail to flash Cure fw then you must have MSM available at least sometimes or you wouldn't have been able to try RMPrepUSB. It's very important you clarify this before we try anything else of a software nature.

I have the following case nuvi 1310:
A friend of mine tried to load fw on unit (as he explained preboot mode->fw), he have loaded fw with HWID 972 (the correct one as 1310 is not MTK), but also and fw with HWID 971 and in that way he apparently bricked the device. He thought that HWID does not matter much....
Somehow he succeed to load again fw 6.30 with HWID 972, or at least g7towin shows that it is fw with ID 972 on device.
Preboot mode - not possible to execute as unit screen is not responsive at any corner and over G. Unit starts ok with Garmin logo and shuts down after aprox. 30 seconds.
USB cable works ok. At WIN7 based laptop at start of the unit device manager program see that there is some Garmin device is connected, but of course I could not access the device.
USB drivers (latest version) are installed.
SD card commands not accepted despite I have tried with 972/971 and even with 1104 (MTK).
Also disassembled the unit, removed battery, checked the connections, etc. Same result with attempts to load FW with SD card.
Question is - what else could I do to revive the unit, as at my level of knowledge, no other options left?

G7ToWin only reads modern devices that are in preboot and also Windows Device Manager only shows them under "GARMIN Devices" when they're in preboot. Therefore for the ~30 seconds the logo splash screen is showing it's actually in preboot and can be flashed using Updater.exe to load correct fw as an RGN file. BTW, SD text commands cannot be used because the device needs to be getting much further into the boot cycle (after "loading Maps" appears on screen) before the card is recognized and Ldr.bin initialized.

So you should simply load an RGN file (named 097201000630.rgn for safety). To make that file use RGN_Tool to convert the GCD file to RGN. Post again if you need further help in that regard.

Yes, no need to give up yet. It may be that there is wrong data in region 5 (i.e. 0971's instead of 0972's) and that foreign bootloader isn't capable of booting the device.

Try to load only the boot.bin from 0972 firmware as 097201000630.rgn. Use RGN_Tool to open the GCD or RGN fw file, uncheck the second and third fields leaving only the first one checked, and then save the boot.bin using the "RGN" button. Flash that using updater.exe to see if it loads successfully and if it can then the device might boot up.