Printable View
I can't answer your first question because this damaged device was a gift to me and I don't know if the first owner did some cross-flash with a different device.
No I don't have the reliable software package with 100% sure that is it ok. Do you have any original software package to share with me?
It is a very challenge to me so solve this issue. :)
My second question only relates to a nonvol backup which you'd also not have seeing you got the zumo already with the problem.
Original "software package" (aka "firmware" or "system software") isn't the problem because you've tried two different versions of the firmware, but you could try downgrading again.
The unit was using latest fw version 4.2 and now I downgraded again as you asked to 4.1 and no USB driver recognized by windows.
I have also cleaned the nonvol memory again with fw 4.1 and still not recognized by windows.
Maybe it is good to make some video conf with you in order to be sure I am executing any mistake that is not being noticed by me. What do you thing about?
We prefer to give assistance in open forum for this kind of problem because other users may also benefit from reading the posts. Anyway, there's nothing more to be gained by seeing the device in a video and i'm sure you're experienced enough to be following the directions and information i've given you. More to consider and things to try:
Clearing the nonvol doesn't completely erase it of course. My earlier question about cross-flashing history was because such attempts often re-map regions and write some semi-permanent data to nonvol that's not 'clearable' but is erasable. Problem is that there is no way to selectively erase the nonvol memory, it must be completely erased. There may not be any material negative side-effects of that, the device will re-create most data correctly for the relevant model/HWID however erasure could result in loss of some features. If you'd like to try completely erasing the nonvol using sd card with 'ergn' text command then read this thread: [Only registered and activated users can see links. Click Here To Register...]. First ensure you sucessfully backup the region, read how here: [Only registered and activated users can see links. Click Here To Register...].
If you want to try but need help in making an sd flash kit then just ask.
I have some more questions:
1) Does RGN Tool takes information from RGN original GCD file from latest fw from Garmin site?
2) Considering my question (#1) is correct I got two options as save boot.bin and also fw_all.bin from RGN Tool. I assumed to use only boot.bin renamed to LDR.bin.
3) At the field "RGN Region" I can see fixed values as "OC "for boot.bin and "0E" for fw_all.bin and nothing related to regions 41 and 154 as I saw in the post you mentioned above.
4) How does the complete ERGN text command set (rrgn,<rgn #>,<output path>) will be written on update.txt file? (rrgn,41,1:/41.bin) ... considering using boot.bin as LDR and also 1 as my Zumo has SD as #1
5) Using only boot.bin and all set as shown above we got the "green progress bar" during the boot saving files to SD card.
6) Using boot.bin as LDR and using SD as #2 and using 41 I got the following update.log file:
===============================================
zumo xx0 Software Version 4.20, UID: xxxxxxxxx, HWID: yyyyyyy
------------------------------------------------------------------------------
Parsing "rrgn,41,1:/41.bin"
Success
Parsing "reboot"
===============================================
41.bin was generated .... I assume that is the Backup of Nonvol and my concern is about 41 or 154 regions that can invalidate 41.bin as a good backup
7) What kind of features can be lost with completely nonvol clean up?
8) I have already decided to Erase NonVol and it was done... see the result:
==============================================
Parsing "ergn,41"
Success
Parsing "reboot"
==============================================
The device still not recognized by the Windows up to now!
You can supply the firmware file to RGN_Tool as either an GCD or a RGN file. It can covert one to another and also splits either file into separate BIN files or can combine BINs in GCD/RGN files. It doesn't otherwise manipulate firmware nor noes it interact directly with a Garmin device..Quote:
Originally Posted by FRCASTRO [Only registered and activated users can see links. Click Here To Register...]
Yes, only Ldr.bin is required to dump regions as BIN files using 'rrgn' command.Quote:
2) Considering my question (#1) is correct I got two options as save boot.bin and also fw_all.bin from RGN Tool. I assumed to use only boot.bin renamed to LDR.bin.
It's hex "0C" not "OC" for boot.bin which is decimal 12. "0E" is decimal 14.Quote:
3) At the field "RGN Region" I can see fixed values as "OC "for boot.bin and "0E" for fw_all.bin and nothing related to regions 41 and 154 as I saw in the post you mentioned above.
Again, RGN_Tool doesn't read anything from the device so it's regions aren't visible to it. It only deals with the Firmware file and it's BINs. Note that BINs are not regions, they are only flashed to regions or they are copies of regions in the form of dumps. Region 41 or 154 is where the nonvol memory is stored and which one's used is device-dependent. It's 41 for zumo 3x0 devices.
"ergn" is used to ERASE a region. "rrgn" is used to COPY (i.e. dump) a region. "xrgn is used to WRITE to a region. In your zumo 390's case the correct path to the microSD is 1 and the nonvol region is 41 so "rrgn,41,1:/41.bin" is indeed correct path/command to copy the bin file to the root of the card.Quote:
4) How does the complete ERGN text command set (rrgn,<rgn #>,<output path>) will be written on update.txt file? (rrgn,41,1:/41.bin) ... considering using boot.bin as LDR and also 1 as my Zumo has SD as #1
Yes that 41.bin is the backup of it's nonvol. If nonvol is in 41 then 154 is either nonpopulated or nonexistant (and vice versa). Don't worry about 154 for your zumo.Quote:
5) Using only boot.bin and all set as shown above we got the "green progress bar" during the boot saving files to SD card.
6) Using boot.bin as LDR and using SD as #2 and using 41 I got the following update.log file:
===============================================
zumo xx0 Software Version 4.20, UID: xxxxxxxxx, HWID: yyyyyyy
------------------------------------------------------------------------------
Parsing "rrgn,41,1:/41.bin"
Success
Parsing "reboot"
===============================================
41.bin was generated .... I assume that is the Backup of Nonvol and my concern is about 41 or 154 regions that can invalidate 41.bin as a good backup
You mean 'erasure' not 'clean up' i guess. In the case of zumo 390 i don't know because i don't have access to one. You're better placed to answer that question seeing you've erased 41 on your device now.Quote:
7) What kind of features can be lost with completely nonvol clean up?
Bad luck then. That means the problem isn't caused by corrupt erasable data in 41 so flash the 41.bin file back using 'xrgn' command.Quote:
8) I have already decided to Erase NonVol and it was done... see the result:
==============================================
Parsing "ergn,41"
Success
Parsing "reboot"
==============================================
The device still not recognized by the Windows
I've now run out of ideas to help you sorry.
I could not notice no loss of features erasing NonVol but I decided to return the backup just to be sure about minor changes that I couldn't observe.
@Butters..... tks a lot for your work with me in this issue and if you have more ideas, please let me know. :)
If other people has some other brilliant idea, please share with us. :)
People ... sometimes the device is simply defective.
@Boki_Srb
I think we've well established that as a fact and there's nothing else to try. My best guess is the problem is due to an irreparable physical error in an essential region of the flash memory.
Exactly...
No magic helps here.