Thread: Is this nuvi 2589 simply Bricked or is it a Hardware Failure?

@VintageDave
The device likely needs to load cure firmware to re-enable Mass Storage Mode so you can remove any corrupt files or as a last resort do a re-format. Read the two threads linked below:
[Only registered and activated users can see links. ]
[Only registered and activated users can see links. ]

Clearly the device can access preboot mode because G7ToWin only works to read devices in preboot. Usually devices that can access preboot can be cured.

Post again if you need more assistance. BTW, your device probably isn't getting far enough into the boot process to read from a card, in any case that file you inquired about [Only registered and activated users can see links. ] is for a device with a different problem, i.e. 'System Software Missing' permanently displayed. Yours is probably 'soft-bricked' which needs a cure fw loaded in the first instance.

Yeah the "T" word here gets more adverse attention than a fox in a henhouse.

This is now seeming to be a more complex problem than a simple soft-bricking caused by a corrupt file which can't be loaded during the boot process.

The behavior you're seeing is worryingly indicative of physical flash damage affecting an essential firmware region, probably region 14 (0x0E) which is absolutely essential for not only normal operation of the device but is also needed to load essential files during bootup as well as executing the loader to start the boot process. Flash damage would explain why Cure3 fw can't be properly loaded too, because if firmware regions can't be overwritten during a flash then corrupt region data is permanent and cannot be corrected by 'soft-methods'. The fact that Windows is reading it in Device Manager as an unknown USB device isn't encouraging either, it should identify itself as GARMIN Device when connected to a PC in preboot.

Let's not give up just yet however. Sometimes severe corruption in one of the firmware regions can mimic flash damage although usually that's corrected by flashing an original fw RGN in preboot. One way to be sure is to use a ramoader (aka boot.bin/Ldr.bin) modified so that it doesn't rely at all on the firmware to initiate a flash. Seeing you have already looked into the modified boot.bin method you likely do understand the reason why we should try that. Please follow the following guide exactly:

• In a hex editor open boot.bin, find the first instance of 0C 80 A0 E1 and change E1 to E3 in that string. Save the change.
• Open the modified boot.bin in RGN_Tool and save it as an RGN file (use only safe naming of 194701000880.rgn), put it aside for now.
• Make a common text file with Notepad, you can copy and paste the text in the coded box below but make sure there are no additional spaces at line ends or carriage returns in it after you save it:

Code:

Please Login or Register to see the links

• Save the file as update.txt.
• Open the firmware file "nuvi25x9C4_880.gcd" in RGN_Tool and save the last 3 sections as 7F.bin, 9E.bin and 0E.bin respectively, naming the BINs after their region hex names and taking care not to mix up the naming (and note "0" is zero). See image below for reference:
  
  Spoiler: Click for Pic

  [Only registered and activated users can see links. ]
• Prepare a small microSD card, preferably no bigger than 8GB ensuring that it's freshly formatted FAT32 and make a root-folder named Garmin in it. In Garmin folder make a sub-folder named Updater and in Updater make another named 1947 (i.e. Garmin\Updater\1947).
• In the root of the card (with, not in, the Garmin folder) copy 7F.bin, 9E.bin and 0E.bin.
• Place update.txt file in the 1947 folder. There should be nothing else in that folder.
• Ensure the device is fully OFF, hold the power button down to force it off if necessary, then insert the microSD.
• Open 194701000880.rgn in Updater.exe, select the radio button for "USB Device" and position your mouse cursor over the OK button of the GUI.
• Connect a 'known-good' USB cable to the PC, plug in the device and place it in preboot watching the window next to "USB Device" and IMMEDIATELY it becomes populated click OK on the GUI or hit the Enter key on PC's keyboard to initiate the flash.
• Keep holding the screen firmly until you receive a popup message from Updater.exe, hopefully it shows that the flash completed successfully.

If that fails please post a copy of the text in "update.log" if it has been generated in 1947 folder.

An explanation of the text commands: The first one will delete a GCD file from the device if there's one present. The second will save a copy of the device's non-volatile memory as a BIN file into the root of the microSD card. The 3rd, 4th & 5th will attempt to write good data to the device's 3 firmware regions. Final one will attempt a reboot.

Good luck. Ask in advance if you're unsure of anything before doing this and be aware it's all at your entire risk although i've been as careful as possible in my instructions. It shouldn't make anything worse however. If the read/write command/s fail/s it will definitively show physical flash damage.

The 16GB card should be ok to use, generally up to 32GB sized cards of most brands can be read by Garmin devices for flashing and even larger cards, i.e. 64GB> provided they're reformatted from exFAT to FAT32. I've had less problems overall using small cards when flashing however.

The uncontrolled boot-looping is another troubling sign TBH. Holding the power button down until the screen goes black should not result in it re-starting spontaneously, it should be hard-off. Regardless, let's press on.

Your suggested sequence is exactly what you need to do. With boot-looping devices i've sometimes had to use my elbow to hit the Enter key, i know exactly that feeling of needing a third hand to click OK fast enough on the GUI.

Even boot-looping devices that can be shut down completely are tricky because they will immediately start looping again when powered on either by the button or a 5V USB connection. Spontaneously powering on adds usually more workload than 2 hands can handle easily so practice the keyboard elbow method. Be persistent because it might take numerous attempts to catch the right moment but provided it's a software problem, once data transmission commences from Updater.exe to the device the boot process will be suspended and the flash will finish without interruption. Unfortunately flashing will always fail if it's a hardware fault causing such behavior. Good luck.

PS: Almost forgot about this:

Do I need another power cycle to execute the new boot.bin and in turn, the region bins in the SD card?

If you believe the "hung" device is waiting to mangle the SD card as soon as it sees it, what can I do? That "device available" window is literally just a few seconds - if I insert the card then, I'll have no chance to start updater .....

If the flash starts and isn't interrupted each command will be executed in turn and if one cmd fails the next will be attempted. However if the flash starts and then fails before finishing there may be a "last_id.bin" file written to the 1947 folder on the card. If so you must remove that BIN before another flash or it's presence will not allow another attempt. If you mean do you need to start from scratch on each flash attempt, then yes. The device must be in a 'power-off' state at least momentarily before each attempt. Your chances of catching it between boot-loops are slim to none so powering it off by holding the button down and then quickly connecting the USB gives you a decent chance. BTW, if the device stays off as long as you hold the button down that'll give you the best chance of all.

There should be no 'mangling' of the card caused by the device boot-looping (i guess you mean causing corruption).

The darn thing won't stay off even if I hold the power button. It's definitely not the way that button should work.

I will try tomorrow morning when I'm fresh. I propose to reuse the 16GB card currently holding my map. It's already FAT32, I'll just backup and erase, and copy in the new payload with the patched boot.bin .

I started to ask about flashing one region at a time, in separate attempts, but if as you say a successful start of script processing captures the system until the whole script has run through, I don't see any point in trying piecemeal if the whole-thing-at-once fails. What do you think?

Originally Posted by VintageDave

The darn thing won't stay off even if I hold the power button. It's definitely not the way that button should work.

No it's not how it should work, and it's also indicative of a hardware problem.

I will try tomorrow morning when I'm fresh. I propose to reuse the 16GB card currently holding my map. It's already FAT32, I'll just backup and erase, and copy in the new payload with the patched boot.bin .

Don't put the patched boot.bin in the card! The flash in this instance is initiated by the RGN file made from it. There should be nothing else in the 1947 folder with the update.txt file. See post #350, one of the step points in that list is this: "Place update.txt file in the 1947 folder. There should be nothing else in that folder.". I suppose i should have highlighted that more.

I started to ask about flashing one region at a time, in separate attempts, but if as you say a successful start of script processing captures the system until the whole script has run through, I don't see any point in trying piecemeal if the whole-thing-at-once fails. What do you think?

Technically there's no reason not to run separate commands but it's probably pointless from a practical aspect. Likely either the flash will start and successfully finish, or it'll fail immediately after it initiates.