Thread: IMPORTANT! If you want HELP in case of a bricked Garmin device, please follow this

@zserv
Unfortunately, there's no known way to 'cure' Android firmware for Garmin devices. Your best approach might be to throw yourself on the tender mercies of Garmin service desk drones. If you get the run-around ask for it to be escalated to a supervisor due to it having been soft-bricked by their software using their own proscribed method. You might get lucky with an even-exchange replacement as it's most likely out of warranty.

1) Bricked device MODEL, Firmware version, HWID.
Nuvi 30, V3.7, 1349
2) Why and how the device got bricked.
It is not necessarily bricked, it is rather resetting to the default file system upon a reboot. If I try to update it either through Express or manually with a GCD file, the file gets erased after a reboot. I tried deleting the onboard gmapprom to put my own custom one onboard, but my custom one was gone and the default gmapprom was put back. Even system settings won't save after a reboot, I have no clue what to do. I got the device used and first noticed the issue when it wouldn't properly update
3) Symptoms: what's wrong in your device?
What I said in 2
4) Does your pc sees your device ?
Yes
5) List all the procedures you already tried to unbrick it and their results and errors messages obtained.
I have tried factory resets, messing with some developer options but even changing dev options (like turning on demo mode) don't save through a reboot.
6) Do you have Garmin USB Drivers installed ?
Yes
8) Write down if you already read and tried everything in these two threads: GarminCure3 tool - the new way to create cure firmwares for Garmin devices and How to unbrick a nüvi - step by step guide
I'm wondering if I should go through the process of GarminCure3 to reflash it, looking for advice as I am quite a newbie here.
Any help would be appreciated

@nsPerFoot
Assuming there really was a file named gupdate.gcd in the Garmin folder before you used the SD card, it seems to have been deleted according to the update.log file. However, my strong suspicion is that the device's internal regions can only be read but not written to. That's backed up by your unsuccessful experience trying to flash Cure3 firmware which is intended to be written to region 14. QuickCure on the other hand is universal and is not firmware dependent, in fact it doesn't involve a device's firmware in any way at all. Similarly, the attempt to flash the 14.bin and 127.bin failed.

I think almost certainly that you're correct, it has a failing flash chip and it will eventually die completely. As you're likely already aware, it's exhibiting much the same symptoms that a bad media card does, i.e. it doesn't save files written to it and deleted files simply re-appear.

@Zakk
Unfortunately it seems your nuvi 30's flash chip is also failing, it just has somewhat different symptoms from those of the previous poster's.

Ah, i see you have solid knowledge of EEPROM workings - in fact far more than i have at granular level given your professional background. Garmin is a queer fish at best and a very closed one at that. It's easy enough to replace the EEPROM physically, it's a common chip i believe and you can swap 13/14xx between other series, such as using a doner unsweated from old 2xx/7xx PCBs with reballing. I've also heard that a simple everyday media card like a small microSD can be micro-soldered in with jumper wires if you know the correct corresponding pinouts. The problem then comes in re-programming the replacement, i have no idea how to do that but unfortunately, it's certainly not as simple as re-loading fw, whether by the SD card process with individual bin files or by loading an RGN file using updater.exe. There were some very skilled users on this and other forums who did know and who had access to the necessary equipment to do such stuff, but they all seem to have disappeared these days. Sorry. I think that with older Garmin devices being so very cheap now that it'd be impractical to pay someone to re-program it anyway but its other individual parts like screen, battery, USB socket (it's a less-common type) and case components like the bezel have some value sold as spare parts anyway. There's still active selling on e-flea for such bits.

I took the my 1390 apart and pried off the PCB's metal EMI shields. The 'logic' side of the PCB has an ARM microcontroller seemingly customized by Garmin, a Samsung 2GB flash memory, and a Bluetooth IC. The other 'analog' side has some GPS and analog amplifier ICs. The Samsung IC is basically a solder-in MMC memory card, which likely makes use of a standard MMC interface in the ARM chip. Most custom ARM chips contain both factory-programmed ROM (not editable) and some flash memory.
My guess is that Garmin has a custom hard-coded loader burned onto their IC, and that in turn loads other FW from a GCD file or similar via the USB port. I couldn't find any obvious PCB pads that supported board-level programming. In my experience we always programmed all flash memory when a product was fully built up, since this allowed for serialization and avoided having to manage multiple versions of commonly-used chips. So, if all Garmin FW lived in the Samsung flash IC, then replacing that and executing the cure process might work. However, if the ARM's onboard flash is also used, then that could be the issue and that chip would also have to be replaced. Both ICs are available from overseas surplus electronics wholesalers, but I decided that life is too short in this case. Flash is usually good for 100k+ write cycles, but is easily damaged by the type of environments seen by our automotive GPS units, such as starting your car with the GPS plugged in, unplugging it from a PC without 'ejecting' it first, and so on. Garmin might also write to the flash during normal operation, which would wear it out after ??? hrs of use. 15 years isn't bad. I guess I'll baby my eTrex 20 going forward!

Spoiler: images

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

Yes, Garmin's ARM processor is indeed customised. It's of course "ARM-like" however operates and boots the device in a "Garminized" kind of way. kunix supplied us with an insight as follows:

Spoiler: click for quote

Try reading the following [Only registered and activated users can see links. ], it's a typical boot sequence of an embedded ARM-based device, including Garmin devices.
So, I can tell the same story of the boot sequence the Garmin-ish way:

1. When you power on your device, the ARM processor starts executing it's ROM code.
   The external RAM modules are not initialized yet, so ROM code would have to use the internal SRAM for stack and data.
   ROM code searches for x-loader somewhere, the copies it to SRAM and executes it.
   On debug motherboards ROM code can load x-loader from SD/MMC or over UART.
   But on release Garmin motherboards ROM code loads x-loader only from starting blocks of the external flash chip. So if you erase those blocks, you will never boot your device again.
   Also those blocks are known as region 43.
2. x-loader is made by Garmin, so it "knows" a lot about the hardware setup.
   x-loader initializes the external RAM. Then, if the external flash chip is NAND, it loads bootloader from region 5 to RAM and executes it.
   Alternatively, if the external flash chip is NOR, the bootloader's addresses are mapped to the address space of the CPU (I don't know, whether x-loader sets up the mapping or it's done by the hardware setup), and so in this case bootloader can be executed from flash directly.
3. Bootloader (the "u-boot") enters the pre-boot mode if a particular key combination is pressed, or if region 14 doesn't pass the "5A A5" test.
   
   In the pre-boot mode the bootloader and the program on the PC (updater.exe, for example) communicate using the Garmin USB protocol.
   If not entered the pre-boot mode, bootloader proceeds to execute fw_all.bin.
   If the external flash chip is NAND, bootloader loads fw_all.bin from region 14 and executes it.
   If the flash chip is NOR, bootoader executes fw_all.bin from flash directly.
   If you erase bootloader in region 5, you will never boot your device again (most probably, because maybe x-loader can load bootloader from SD, but it's highly doubtful).
4. fw_all.bin (the "kernel") is responsible for
   
   • drawing the usual GUI
   • for providing the mass storage mode and the MTP mode.
   • initiating the procedure of executing update.txt scipts.
   • initiating the procedure of flashing GUPDATE.GCD files and verifying GUPDATE.GCD digital signature.
   • also, if not in the mass storage/MTP mode, it can communicate with the PC using the Garmin USB protocol and it provides a very rich set of USB commands
5. boot.bin (the "ramloader") is responsible for:
   
   • flashing regions over USB in pre-boot mode. It also communicates with with the PC using the Garmin USB protocol.
   • very frequently boot.bin contains copies of bootloader and x-loader and flashes them, when executed.
   • flashing regions from GUPDATE.GCD files.
   • executing update.txt scripts.

Every piece of Garmin firmware (i.e., x-loader, bootloader, fw_all.bin, boot.bin) contains a table of regions, which specifies which regions are contained on which flash chip and where exactly.
Also people frequently confuse bootloader and boot.bin. They are different.
Also region 41 (NV) is parsed only by fw_all.bin, other pieces of firmware (x-loader, bootloader, boot.bin) treat it as an opaque massive of bytes.
So if NV is corrupt, fw_all.bin may crash even when entering the mass storage/MTP mode.
But other pieces of firmware (x-loader, bootloader, boot.bin) continue working correctly.

I can add that the Garmin OS of your 1390, although Linux-based, is very far from basic Linux and is a proprietary "closed-shop". We can garden around the edges by modifying firmware but AFAIK nobody has actually been able to get into the OS proper or if they have done, they haven't made it pubic.