aera 795 stuck on 'Loader' after fw update (could getting Unit ID from GMA or UNL files help?)

That's disappointing. However, i've had another thought, perhaps this device writes to the card using path "1" like some much older auto devices. This is worth trying, open the update.txt file in Notepad and select Edit>Replace, then replace ",2:" with ",1:" like in the image behind the spoiler:

Spoiler:

[Only registered and activated users can see links. Click Here To Register...]

Note: Before you attempt to use the same card, remove last_id.bin file from the 1364 folder or it may interfere with further use of that card for this purpose.

If that doesn't work it's quite safe to try dumping some regions from your friend's aera as a test, you can use Ldr.bin in the 1364 folder and simply start the device because his device is healthy (no need to use RGN and Updater.exe). Again, always first remove last_id.bin.

Thanks again Butters. What a twist :-)

I had to dump the flash in 3 runs as it did not dump all of it at once. By far the largest region is 48.bin. The entire dump and update.log is in the archive below.

Spoiler:

[Only registered and activated users can see links. Click Here To Register...]

Gee, i guess i shouldn't be surprised. Old saying by anyone who's had much to do with them: "Garmin is so Garmin". The inability to dump all regions at once is a throwback to a characteristic of automotive devices even older than those which read/write the card as "1". Nonvol is in rgn41, rather than the later trend of using rgn154. I'm also a little amazed at the small flash size on such a complex device, it seems it's no bigger than 2GB. The encouraging news is that viewing the dumped regions this device seems physically healthy as far as i can tell. So, a software solution is likely but i still have a lingering suspicion of some flash damage but if is there but minor and confined to the visible parts of the flash we can easily work around that if the next steps fail. The File System is indeed in rgn48, another 'older' characteristic. When 48.bin is extracted and examined i see that there were 4 new files added at 15.32 on May 4, that's when you used WebUpdater and it bricked i guess? Two of those files are gupdate.gcd [update fw v5.60] and gmaptz.img [time zone map V22] which i've been able to compare to known-good files and their hashes match so we can rule them out for the present. The other two are in RemoteSW folder, 006B134300.gcd & 006B251300.gcd and they're my main suspects.

Spoiler: pics

[Only registered and activated users can see links. Click Here To Register...]

There is another file in the GPX folder named Current.gpx added at 13.36 but not such a likely suspect and i guess that was the last time the aera was used before the update with WebUpdater at ~15.30 that day. Let's delete those 2 main suspect files from RemoteSW and see if that frees it up to properly load the V5.60 fw from gupdate.gcd on reboot. If this works, "Loader"/"Software Loading" or similar should show briefly on reboot and then it'll start normally, updated to V5.60.

You know the drill by now, look behind the spoiler. Open your card's 1364 folder and remove both last_id.bin and update.txt and replace with the new update.txt below. Load the modded RGN into Updater.exe then connect in preboot, etc.. Good luck.

Spoiler: txt file

[Only registered and activated users can see links. Click Here To Register...]

Quote:

---

Originally Posted by Butters [Only registered and activated users can see links. Click Here To Register...]

When 48.bin is extracted and examined i see that there were 4 new files added at 15.32 on May 4, that's when you used WebUpdater and it bricked i guess?

---

Quote:

---

Originally Posted by Butters [Only registered and activated users can see links. Click Here To Register...]

There is another file in the GPX folder named Current.gpx added at 13.36 but not such a likely suspect and i guess that was the last time the aera was used before the update with WebUpdater at ~15.30 that day.

---

Both your statements are correct. It must have been turned on at 13.36 (in panel mount). I only got to start updating it at about 15.32.

I ran the update file deleting the two GCD files from the RemoteSW folder. The log indicates success but the unit still gets stuck during boot the same way as before. After splash screen it displays "LOADING..." and that is it.

Spoiler:

[Only registered and activated users can see links. Click Here To Register...]

How about deleting all update files from this date? Although, I do not know what is the current SW status as the unit says (except on the splash screen) it has 5.60.

The only other GCD with that same date is GUPDATE.GCD which has the same hashes as the one i downloaded directly from the Garmin server. That's not to conclude categorically there's no corruption. Both files might well have a problem (a bug) if it was just issued but version 5.60 has been available since March 25. Regardless, it wouldn't be a problem if you want to delete it, just use "del,0:/System/GUPDATE.GCD". Copy and paste that into update.txt after removing the original text commands, but I've looked again at the remaining files in RemoteSW and there is one with a very strange date. Maybe your current ride is a Time Machine and you popped back to celebrate the New Year in 1600 because the date shown by the BIN extractor is 1601-01-01 for 006B168600.GCD. Use the command "del,0:/.System/RemoteSW/006B168600.GCD" to get rid of it and see if the aera boots before you remove GUPDATE.GCD.

If all that doesn't work, best to just delete all remaining GCDs from RemoteSW using this:
del,0:/.System/RemoteSW/006B136200.GCD
del,0:/.System/RemoteSW/006B136201.GCD
del,0:/.System/RemoteSW/006B137900.GCD
del,0:/.System/RemoteSW/006B168600.GCD
del,0:/.System/RemoteSW/006B176900.GCD

You can add the other two commands to the above to delete 006B168600.GCD and GUPDATE.GCD if you want to do all in the same single flashing. Add "reboot" as last line of course.

Ensure there are no unintended spaces or carriage returns included if you copy/paste the above commands and also remember to delete any last_id.log from 1364 folder before re-using the card.

If it remains stuck on "Loader" we can dump the file system again to check that those files are actually being deleted (some badly corrupted files are stubborn to delete and flash damage can also interfere with proper deletion).

Quote:

---

....... I do not know what is the current SW status as the unit says (except on the splash screen) it has 5.60.

---

How did you determining the on-board version, by using G7ToWin in preboot? If so, did it hold in preboot for an extended period or drop out after a short time?

All working now. Amazing!

First, I deleted that suspicious file (created in 1600) but this did not work. Then I deleted all remaining GCD files in RemoteSW folder but his this did not work either. Finally, I deleted the GUPDATE.GCD and that was it. The unit booted, took quite long to initialize the terrain database but then all was working. When I plugged the USB in it enetred MSM too.

After this I was confident enough to try to update to 5.60 using WebUpdater again. After this I had the same behaviour as before. Stuck at "LOADING..." After deleting the GUPDATE.GCD I had it working again. I thought maybe I could try using GarminCure3 and original SW downloaded from Garmin. This ended up "bricked" too. Then I realized the clock on the unit was wrong. I remembered somewhere on this forum I read that Garmin units only fully initialize once they catche position. I deleted the GUPDATE.GCD once again, got it running, went outside and let the unit acquire 3D position. Then I tried WebUpdater again and then, after another restart, it finally installed 5.60 SW.

Now it is all up and running. :happy:

A huge thanks to everyone on the forum for all the tools and knowledge. Especially to you Butters!

Great result. The big thanks needs to go to kunix for his simple mod to Ldr.bin enabling it to run txt commands as an RGN!

I'm constantly surprised how little details such as an incorrect time can sometimes mess up an intended update. By any chance did you reset the aera in the couple of hours you last used it before the update about 15.30? Even removed the battery during that period before that update attempt?

Webupdater should have also replaced the minor GCD files dated May 4 into RemoteSW folder if they hadn't been initialized previously. If they were indeed loaded on boot at some point they're not needed now though and the GarminDevice.xml (which updates on each full boot cycle) will reflect that to prevent unnecessary repeat downloading. If you want them to add back into RemoreSW let me know as i have copies.

(Suggestion for Moderator: Perhaps this thread should now be marked as "Solved" with some change to title reflecting the real problem?)
:mn: Done, thanks. Title changed from "Getting Unit ID from GMA or UNL files" to "aera 795 stuck on 'Loader' after fw update (could getting Unit ID from GMA or UNL files help?)"

Quote:

---

Originally Posted by Butters [Only registered and activated users can see links. Click Here To Register...]

By any chance did you reset the aera in the couple of hours you last used it before the update about 15.30

---

I am not aware of it. I always check what is the status of individual aviation databases. They are all listed on the first screen after boot and I need to acknowledge their expiration dates in order to get to the system. I do not see any reason why I would have needed to remove the battery in order to power it off from at this point.

Quote:

---

Originally Posted by Butters [Only registered and activated users can see links. Click Here To Register...]

If you want them to add back into RemoreSW let me know as i have copies.

---

I think I have them all again as WebUpdater installed it all:
[Only registered and activated users can see links. Click Here To Register...]

I believe this is mostly optional SW to enable or update functionality of some features (such as wireless AHRS & ADS-B data transfer (Garmin GDL39) etc.)

To moderators:
Although proved UID can be obtained from an UNL file (which was my initial idea to solve the issue with Garmin) this was not helpful. Basically Butters' posts #4 and #15 include all ideas that were needed to unbrick the device.

Then i guess the wrong time display was a result of 'a time freeze' while it wasn't able to boot for extended periods cumulatively while stuck on 'Loader' and of course it was then lacking a valid satellite fix to auto correct the time for the entire period it was indoors.

Yes indeed, WU thought those minor GCDs weren't loaded so gave them again.

For the sake of completeness :), the link to the small program that can extract information from an UNL code: [Only registered and activated users can see links. Click Here To Register...].
Here's to safe flight always! :beer: .... 8 hrs after the beer of course ;).

Hello and thanks for having me with you. I am a new member here as I recently acquired a used Garmin 795 which seems to be bricked.

Since 3 days I am looking in this thread ...

My case is a bit different as I don't know what bricked the device in the first place and it is not stuck in "Loading..". No it just turns on. Shows the Garmin Logo and then turns off again. When connected to USB it just loops and loops on.

But did not get farther too much, besides than having been able to but the device in pre-boot mode somehow and be able to execute commands from the update.txt file. But even in pre-boot mode and when running Garmin Cure3 it is still booting in between somehow. (Or maybe when finished the commands)

Anyway. Someone dares to help me out?

Many thanks and Regards
Ben


P.S.: I was able to make a dump of the bin files, in several attempts. The device was able to dump some files, then rebooted again and I rewrote the update.txt each time to start directly where the last dump was interrupted. So I have 255 *.bin files, but I do not know how to extract them, as it was not really clear for me from the thread. Would really appreciate some help