Thread: Nuvi 58LMT "can't unlock maps".

That was sort of what I was attempting to say probably with completely wrong terminology. I was relying on the "power off" option not a nonvol clear.

So with a nonvol clear I'm back to the errors until I insert the SD card fix. Then it works fine without the SD card until next clear. It doesn't know/care that the gmapprom.unl (and gmapprom.gma?) on the internal flash aren't valid and doesn't attempt to recheck it unless it changes in some way. Reinstalling the map with GE doesn't count as "changes".

Is there some documentation above the noob level indicating what all the filetypes do, what's known about them and pointers to tools to mess with them? I know some of the answers to that for .unl but not the other types. I'm hoping to educate myself enough to be able to fix this myself (and maybe help someone else) if/when this happens again.

I'm very happy that it's no longer a brick but there's that little bit of me saying it would be even better if it could work without needing the SD card fix on every hard reset and if I knew how to create the files to do that, if it's possible.

Update... reread the thread and tried what GN said might work earlier. Replacing the bad .unl and .gma files in internal flash with those on the SD fix and after a nonvol clear it's all working fine.

I'll go away and leave you all in peace now

What i was saying in my previous posts is this, in highly expanded paraphrase:

• Following a reset/clear NV, GMA and UNL codes in visible memory are initially read, checked against the map IMGs present to ensure they are valid for them, copied and then stored by the devices somewhere on its (not user accessible) internal memory, i'm absolutely 100% certain that they're exclusively written to its clearable NV (note: codes can also be inserted into the map IMG file too rather than as standalone *.unl files - from the IMG data they're read and copied the same as codes in UNL files are treated from the visible internal or external memories);
• Since those codes, now stored in non-volatile memory, were successfully checked via some 'majic' by the device during initial re-boot in that they're found to match with the maps, the device no longer looks for them in visible internal or external memory. So, it only checks on subsequent re-boots that the valid codes remain in NV, it doesn't matter about what's in normal memory because it won't even look there again unless the code data in NV's either missing or it isn't valid for the current maps. The device also overwrites the GarminDevice.xml on reach successful reboot from the wealth of general and unique info stored in NV - that's why manually rewriting any data to the XML doesn't work on the device, it just re-writes it completely on each reboot from the unique NV memory data, both temporary and permanent. Just some of the latter's data seems to be also stored elsewhere because only part of the programmed permanent data is restored to the NV region following erasure of its data. Clearing NV on the other hand is just a very comprehensive hard-reset.
• Therefore, removing codes from visible memory or even replacing them in there with invalid codes doesn't matter - that is of course provided the correct data's still in temporary NV. Until the next hard-reset or clear NV the device will happily function regardless of countess reboots.

So i think you'll now clearly understand why the faulty (invalid) UNL code (with FID "1") is ignored if present. On the other hand, GN's supplied UNL for full EU does work for your UK/ROI because it is valid for any and all parts of EU (FID 12956). Once that code's been parsed and passed to NV, the SD card's presence doesn't matter because the code data's been correctly written to NV memory as explained above. However, Garmin's OS and many of its processes and even the function of many of its "regions" remain a mystery to me and many others outside of Garmin. If anyone has managed to really 'get under the bonnet' like we can with Linux or even Windows they've kept it real quiet.

Try making your own valid UNL code with JetMouse, i bet it'll work the same as the SD card UNL file from GN does after a reset provided the GMA file is present with it.

You've got formal programming experience, that's very clear to me. I don't, i'm only an enthusiastic and somewhat incompetent amateur. GN i suspect is also quite more like me than you in coding experience.

So it you wanna know more, go ahead - [Only registered and activated users can see links. ] - i dares ya.