Welcome guest, is this your first visit? Click the "Create Account" button now to join.
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29
  1. #11
    Member
    Join Date
    May 2010
    Location
    Prague
    Posts
    17
    Rep Power
    0

    Default

    Thanks for your advice Butters,

    I think I have tried many, many combinations and timings. You wrote this procedure on this forum several times - have the updater ready, press updated immediately after the Updater recognizes the unit etc. I really tried all of it so many times...

    I am thinking there has to be something else preventing it to flash correctly or I am doing something wrong. Let me summarize how I understand the procedure and list some of my questions:
    1) I have the cure RGN genreated by the GarminCure3 tool. It says "Processing OK " Unce I click on Updater.exe button it creates a temp folder with the RGN in it

    2) I read somewhere the RGN file must be in the same folder as Updater.exe. So I also tried moving this generated RGN file to the same level where Updater.exe is and then launche the updater by dragging the RGN file onto it

    3) I have all executables set to start as Administrator

    4) I also tried updateing my Garmin USB drives to the latest version (2.3.1.2) and downloaded the newest Updater (2.8.0.0)

    5) When I load the GCD file into the RGN tool it shows boot.bin and fw_all.bin with correct HWID (1364) and SW Version (560) but it also shows 4 more "Unknown.bin" files where HWID and SW Version is just NA. Is this correct?

    6) There are two official Garmin master reset procedures. The one that also wipes nonvol requires the unit to be in the stand. I also tried numerous times to flash while in the stand.

    7) From the "How to unbrick a nüvi" document I understand I should be holding the power button during the entire updating process. This means that after the first phase of updating the unit restarts and then enters preboot mode again. The second phase begins but the Updater only goes to 2 % and then disappears. No message or anything.

    8) No matter what happens, if I do not enter preboot it still shows the old SW version (550) and then shows LOADER which is a dead end and battery needs to be removed.

    I can make a video of the process if it would be helpful. Also I want to apologise for creating this thread. I believe this should be a part of the GarminCure3 thread.

    Thank you very much for your support!
    Last edited by Boki_Srb; 10th May 2020 at 05:19 PM. Reason: approved

  2.    Advertissements


  3. #12
    Member
    Join Date
    May 2010
    Location
    Prague
    Posts
    17
    Rep Power
    0

    Default

    Hello,

    I have a little update. If I use GarminCure3 to generate the RGN file, the first update phase takes about 5 seconds to complete, then the unit restarts and then the Updater just disappears.
    If I use RGN tool to generate the RGN file, it only takes about a second to complete the first phase. It is much quicker. The same GCD file is used in each case. I was just wondering if this could indicate something...

    I also tried to use another cable and another PC. My PC has Win 10, I tried on Win 7 too. The same behavior was observed.

    Once the updater disappears (after restart) the unit remains in the boot mode even without holding the power button. It remains connected and when I launch Updater again it still recognizes the unit.

  4. #13
    Master Butters's Avatar
    Join Date
    Jul 2017
    Location
    CA
    Posts
    899
    Rep Power
    140

    Default

    Quote Originally Posted by MY58002 View Post
    ........
    2) I read somewhere the RGN file must be in the same folder as Updater.exe. So I also tried moving this generated RGN file to the same level where Updater.exe is and then launche the updater by dragging the RGN file onto it
    They only need to both be in the same folder (directory) if you intend to load the RGN by starting Updater.exe, otherwise drag and drop should work fine if they are in different locations. Drag and drop doesn't work in GarminCure3.exe if set to run as Admin though.

    3) I have all executables set to start as Administrator
    Try again without "Run as Adminstrator" checked for Updater.exe and/or also change compatibility to an earlier version of Windows, even try XP. However both V2.7 & 2.8 of Updater work fine for me in Win10_64.

    5) When I load the GCD file into the RGN tool it shows boot.bin and fw_all.bin with correct HWID (1364) and SW Version (560) but it also shows 4 more "Unknown.bin" files where HWID and SW Version is just NA. Is this correct?
    RGN_Tool is older than much of the fw existing today. Sometimes it isn't sure 'what is what' in regard to regions and sections so i'd suggest if you want to check the RGN file's BIN components you use this instead: [Only registered and activated users can see links. ]. It's much better at correctly identifying the contents accurately and the author of both Cure 3 and gfw is kunix so there'd be no cock-ups in either i'd think .

    6) There are two official Garmin master reset procedures. The one that also wipes nonvol requires the unit to be in the stand. I also tried numerous times to flash while in the stand.
    As you've found this problem cannot be rectified by a reset/clear nonvol. I don't think you need to have it in the cradle for flashing either.

    7) From the "How to unbrick a nüvi" document I understand I should be holding the power button during the entire updating process. This means that after the first phase of updating the unit restarts and then enters preboot mode again. The second phase begins but the Updater only goes to 2 % and then disappears. No message or anything.
    8) No matter what happens, if I do not enter preboot it still shows the old SW version (550) and then shows LOADER which is a dead end and battery needs to be removed.
    Worst case scenario is physical flash damage exists. Let's assume otherwise for the present and press on.

    I can make a video of the process if it would be helpful.
    If you want to go to the trouble, sure do that. However it's not necessary ATM.

    Also I want to apologise for creating this thread. I believe this should be a part of the GarminCure3 thread.
    A mod has been approving some of your posts which must have been sent to the moderation queue for approval, perhaps your IP is causing that. Regardless if Boki_Srb thought it belonged elsewhere, he'd have likely moved it already. Personally, i think your problem is more than a little different from the 'run of the mill' everyday brickings of common devices and additionally it's an aviation unit so as such deserves it's own thread for both reasons.

    Good luck. Persistence sometimes pays off with stubbornly bricked devices.

    EDIT: Gah! Your next post made 17 mins before mine was also moderated and i didn't see it before i posted as above.
    Quote Originally Posted by MY58002 View Post
    Hello,

    I have a little update. If I use GarminCure3 to generate the RGN file, the first update phase takes about 5 seconds to complete, then the unit restarts and then the Updater just disappears.
    If I use RGN tool to generate the RGN file, it only takes about a second to complete the first phase. It is much quicker. The same GCD file is used in each case. I was just wondering if this could indicate something...
    Well, the two RGNs are different files in that one is a 'standard' firmware and the other a 'cure' firmware. There's no point you trying to flash an original (unmodded) RGN anyway whether it's the same version as already on-board or later because the reason the device isn't starting is that it cannot load a file that's already on the device. The way GCD and some other update files and RGN files are treated differ immensely. An RGN is flashed by Updater.exe directly to the relevant regions whereas in modern Garmin devices other files like gupdate.gcd for example are first loaded to a directory in the device's visible file system (also a 'region' but a special one, in your aera probably region 83). In the latter case, the flashing is delayed until the next boot when as part of the start-up sequence the device will attempt to load those files appropriately, e.g. the components of a new (later fw version) gupdate.gcd in the root of .System are loaded (flashed) to the respective regions and other lesser updates in .System\RemoteSW folder are also activated. I believe it's one of those minor files causing the problem provided the device is otherwise healthy.

    I also tried to use another cable and another PC. My PC has Win 10, I tried on Win 7 too. The same behavior was observed.
    Not an operator error it would seem going by that.

    Once the updater disappears (after restart) the unit remains in the boot mode even without holding the power button. It remains connected and when I launch Updater again it still recognizes the unit.
    Yes however you'll not be successful in getting a flash initiated in that situation in my experience. Best to power off and start again.
    Last edited by Butters; 11th May 2020 at 01:01 PM.

  5. #14
    Member
    Join Date
    May 2010
    Location
    Prague
    Posts
    17
    Rep Power
    0

    Default

    Thanks Butters for your replies!

    I am just thinking, is there a way to get a log from the Updater? Sometimes after restart I see "Erasing 0%" sometimes I see "Erasing 2%" or "Updating 0%" or "Updating 100%". Ragardless of what I do, after some 100+ attempts I still get the same result. The Updater just disappears without any message. Once when running it with Windows Vista compatibility mode I heard standard windows error sound when the Updater disappeared. There was no window or anything. Sometime when running the updater in older Windows compatibility modes a get the "Out of memory!" warning message form the updater and then it crashes.

    I am wondering maybe it gets stuck exactly at the same moment and ther would be a way to see if this is true.

    Thanks.

  6. #15
    Master Butters's Avatar
    Join Date
    Jul 2017
    Location
    CA
    Posts
    899
    Rep Power
    140

    Default

    I don't think there are any usable Windows log entries which will give more information. Updater.exe is not installable only standalone therefore has minimal interfacing with the PC's OS but check Event Viewer for logs if you want. Regardless, the problem is with the device and error logs if they exist would only tell us what happened to Updater and that we already know: It gets someway into it's flashing attempt i.e. x% erasing before crashing. (In explanation, a region is erased then re-written with fresh data rather than being overwritten). I believe the times "Updating 100%" is seen is mis-reported somehow because the complete flash clearly hasn't happened, not even the initial erase as you still have V5.50 onboard. That "Out of memory" message is probably from using an earlier 32bit Windows.

    It seems there won't likely be any success with Updater used like this if your report of "some 100+ attempts" isn't exaggerated. I once restored fw on a stubborn old-style (region only, no visible file system) auto device given to me as a 'write-off' on the 96th try. Every morning i made 10 attempts and on the 9th day the 6th attempt worked, but that's an exceptionally rare case with a different type device with a different problem and usually if the preboot>flashing sequence is properly followed (no operator error - VERY common but not in your case i think) a repairable modern device will be quickly successfully flashed provided other factors like USB cable, proper USB2 port without hub etc. are eliminated.

    Time to try something else. First let's see if it can read from and write to the SD card. I doubt it will be able to do that in the normal fashion but it's worth a test try to dump nonvol region 154 before using a modified boot.bin as RGN in combination with Updater hopefully forcing a txt command in sd card.

    The test: Extract the attached compressed file from behind the spoiler below to find a folder "Garmin". Place the Garmin folder onto a CLEAN sd card first ensuring the aera is completely OFF then power it on. Let me know if any different screen behavior is noted. If the device turns off or attempts to reboot remove the card. If nothing changes after several minutes remove the card anyway. Browse it and note if there is a new file in the root named 154.bin and even if it isn't there look in Garmin\Updater\1364 folder for a new file named "update.log" and post it's contents if present.
    Spoiler:
    [Only registered and activated users can see links. ]

    If that doesn't work we can try with the modified ramloader next.

  7. #16
    Member
    Join Date
    May 2010
    Location
    Prague
    Posts
    17
    Rep Power
    0

    Default

    Quote Originally Posted by Butters View Post
    Once the flash starts properly the device will hold in preboot until it finishes.
    Do you mean that once I see the loader initiated on the screen I no longer need to be holding the power button? Should it enter preboot mode automatically after the first phase and subsequent restart without me holding the power button and forcing it into preboot again?

    Does it matter how the preboot mode is entered? I realized I can enter preboot just using the power button. USB cable can be inserted any time afterwards. The unit remains in preboot for about 18 seconds. Also, once the first flashing phase is initiated, I no longer need to be pressing the power button but then the restart happens quickly and timing differs on each attempt. Generally there is very little time to start pressing the power button again to force it into preboot after restart. Pressing the power button with loader active just turns off the device which then starts again because the USB cable is connected.

    I do not know if this could make any difference. I did most of my attempts holding the power button all the time.

    Quote Originally Posted by Butters View Post
    First let's see if it can read from and write to the SD card.
    I tried your SD card file but I did not find any log file. I think that during the booting process the unit does not get to a point where it reads from SD card before the loader is initiated.

  8. #17
    Master Butters's Avatar
    Join Date
    Jul 2017
    Location
    CA
    Posts
    899
    Rep Power
    140

    Default

    The statement kind of stands for itself: "Once the flash starts properly the device will hold in preboot until it finishes" - in other words preboot won't drop while there is a proper connection with data transfer between Updater.exe and the device. A flash is generally considered to have started properly when "Loader" shows on the screen however that might be not considered conclusive in your device's case of course. Certainly if you see "Software Loading" after some seconds it's flashing correctly and you can safely release the power button however it's fine to hold it until updater.exe reports success. This info is now likely moot anyway because you've been unable to flash it 'conventionally' in preboot.

    Your lack of result with the card commands wasn't totally unexpected and provided the device is physically healthy, your assumption is likely correct in that the boot process is not getting far enough along to read from the card as it's being relegated by the attempt to flash something from the internal device memory first. Time to try using a modified boot.bin/Ldr.bin as an RGN, this is an attempt to get the card read before stuff is loaded as part of the 'normal' boot process and if it doesn't work i have no further suggestions and would strongly suspect physical flash chip damage. You'll need a hex editor for this, i mostly use XVI32 which is freeware however any hex editor will do. Here's the procedure:
    • Go the Ldr.bin file which you find in the 1364 folder and copy or move it somewhere onto your PC. REMOVE the Ldr.bin file from the card afterwards if you only copy it.
    • Look at this Post #33: [Only registered and activated users can see links. ].
    • Make another copy of Ldr.bin to work with, keeping the original. In a hex editor open that copy of Ldr.bin (it's the boot.bin, which is actually the ramloader ... what? It's Garmin ...), locate and make the change in the 4-byte string from '0C 80 A0 E1' to '0C 80 A0 E3' then save in a separate location.
    • Open the modified Ldr.bin in RGN_Tool and press the "RGN" button, save it as 136401000560.rgn somewhere convenient.
    • Go back to the 1364 folder on your sd card and make sure the only file there is 'Update.txt' before proceeding.
    • Put the card into the aera, making sure it's fully off.
    • Open the 136401000560.rgn file in Updater.exe, start the aera in preboot and try to flash.

    Good luck! Hopefully this time you'll have a file 154.bin in the card's root and/or a file update.log in the 1364 folder.

  9. #18
    Member
    Join Date
    May 2010
    Location
    Prague
    Posts
    17
    Rep Power
    0

    Default

    I prepared a new RGN file per instructions above, flashed succesfully, saw "LOADER VERIFYING SOFTWARE" on the screen and then the device rebooted. Now there are 2 new files in the 1364 folder: last_id.bin and update.log. The only output in the log is "Error".

    What I find quite strange is the the unit returns SW version 5.60 in the log but it displays 5.50 when it is trying to boot normally.

    The qustion is: is this good news or bad news? :-) I do not see anything good in the log file.

    Thanks!

    Spoiler:
    [Only registered and activated users can see links. ]
    Last edited by MY58002; 13th May 2020 at 07:46 PM.

  10. #19
    Master Butters's Avatar
    Join Date
    Jul 2017
    Location
    CA
    Posts
    899
    Rep Power
    140

    Default

    Definitely good news, potentially. I didn't even know if the aera 7xx actually has a working region 154, most likely your result means either (i) it's present but protected against copying, or (ii) it isn't present at all. Either of those situations gives the 'error' return for that rrgn command. The good thing is that it tried to copy 154 which is the most common region for nonvol in modern devices. It indeed parsed the 'reboot' command successfully but of course the device just isn't able to complete the boot cycle.

    This result doesn't entirely rule out flash damage however. It could be that 154 is indeed present and unprotected against copying on a healthy aera 795, but the region on yours is physically corrupt although quite less chance of that i think. Let's press on and see if we can get a full region dump of regions 1 thru to 255, in particular it's the file system content that we want, which is either region 48 or 83 on most devices. We also want the nonvol if it's not protected and in a region other than 154. This will take some time to complete and you may not want to constantly watch it to note a boot attempt before removing the card however even if you interrupt it after, say 30 mins or more, it will probably have dumped enough. Ensure the battery is charged at least 75% and the usb port and cable used is reliable. Many of the possible 255 regions either will be empty (i.e. dumped *.bin file has 0 bytes) or not exist on the device (error message in update.log as shown for 154 in your previous attempt). Regardless, we'll try to dump everything for completeness. I've attached a complete kit behind the spoiler so extract it onto a CLEAN card then proceed as before using the ramloader RGN with Updater.exe in preboot. I don't know the size of the 795's flash memory but i suspect it's quite large. Use a 32GB card if you have one or minimum 16GB card (or even use a 64GB or larger one but ensure it's reformatted in FAT32 not the default exFAT). If you only have an 8GB card use that anyway, we'll likely get something worthwhile even if it's just the reassurance that it can successfully dump some regions.
    Spoiler:
    [Only registered and activated users can see links. ]

    We'll have quite more to do later if this works but ongoing we'll hopefully have the knowledge of what's actually contained in the device's folders and files. It may be a little frustrating that this is taking a long time to work thru because i'm taking baby steps with this repair procedure. I'm doing that because (i) It's still an expensive device, over 2 grand US when released in ~2011 and a good 2nd hand unit's value is prob up to $1000 still; (ii) I don't have one that i can easily access to test stuff on [i have a PPL but just like me all my pilot friends are just too poor or too cheap to own a nice bit of kit like that ] and (iii) I'm trying to use the policy of "do no harm" here.

    There's still a chance there's flash damage of course but instinct and previous experience now tells me that's not so likely. Good luck and post the outcome when you can, i may not be available for a while to get back after you do so please be patient awaiting my response to your next post. You'll need to use a hoster site like Zippyshare or Anon files etc. for a good result because even at maximum compression it'll be much too big to attach on our server. If every single region dump fails (proving flash damage) then it'll be quite small.

    PS: No change to 5.60 on boot screen is not unexpected and is nothing to be concerned about. The BIN component of that RGN has not been flashed to the device, it's just used to start the card txt commands. There is no actual update with that method so V5.50 still shows.
    Last edited by Butters; 14th May 2020 at 02:04 AM.

  11. #20
    Member
    Join Date
    May 2010
    Location
    Prague
    Posts
    17
    Rep Power
    0

    Default

    Thanks Butters for all your help! I really do appreaciate it very much. I am amazed by the extend of in-depth knowledge on this forum.

    Sadly, I think we now have a proof of physical flash damage. I tried a few times but the result was always the same: it returns Error for all regions.

    Spoiler:
    [Only registered and activated users can see links. ]


    A friend of mine also has an aera 795. I could try to dump his flash if it would not damage his unit in any way. Just to see if it is protected.
    Last edited by MY58002; 14th May 2020 at 07:29 AM.

 

 

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •