Thread: Windows cannot detect internal and SD memory for Zumo 390LM

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. ]. First ensure you sucessfully backup the region, read how here: [Only registered and activated users can see links. ].

If you want to try but need help in making an sd flash kit then just ask.

Originally Posted by FRCASTRO

I have some more questions:
1) Does RGN Tool takes information from RGN original GCD file from latest fw from Garmin site?

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..

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.

Yes, only Ldr.bin is required to dump regions as BIN files using 'rrgn' command.

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.

It's hex "0C" not "OC" for boot.bin which is decimal 12. "0E" is decimal 14.

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.

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

"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.

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

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.

7) What kind of features can be lost with completely nonvol clean up?

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.

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

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.

I've now run out of ideas to help you sorry.

@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.