Thread: Trying to unbrick a zumo 220

From post #8:

Originally Posted by Neil

Just as quick to make it for you really, so here it is:

Spoiler: Click

[Only registered and activated users can see links. ]

Usual stuff, drag it onto Updater.exe, connect in preboot mode and hope it flashes.

The flash was successful, but it made no difference to the symptoms of the zumo.

Well... not completely true. There is a difference in that the unit does not switch off anymore after 3 seconds when on battery power. It stays on now (still frozen on the Garmin splash screen) until switched off manually by pressing and holding the power button for more than 5 seconds.

Originally Posted by kunix

If it doesn't help, I would suggest dumping fw_all.bin with rrgn,14,1:/14.bin and comparing it to the flashed one.

I don't fully understand. There is a rgn14 in the unit which I can dump as described. What exactly do I compare it with?


Edit 1:
I notice that since the above action, the zumo is not recognised anymore by the PC, WebUpdater or Garmin Express.

Edit 2:
Had to flash CURE FW into the unit via GarminCure3 and Updater.exe to get it recognised again by PC etc.

Originally Posted by smokefree

..... I don't fully understand. There is a rgn14 in the unit which I can dump as described. What exactly do I compare it with? .....

As one firmware mug to another, i'll try to help you understand to my limited extent, while kunix wrestles with some more advanced possibilities for your very sick unit. The dump of region 14 is the unit's firmware, i.e. fw_all.bin. Even though 14.bin may be quite a bit larger by a lot of FFs tacked on at the end, they otherwise should be the same before there. I think comparing them in hex to see if there are any other differences before the padded bytes will show whether fw_all.bin is being properly flashed.

Dump it and kunix will tell you what to do if the hex compares don't match. This might help you, HexCmp2:

Code:

Please Login or Register to see the links

SF, i'm waiting for kunix to answer you learnedly, but my horse-sense is that it's pointless comparing the packed fw_all.bin to the dump of 14.bin [whether dumped after either original, cure or packed fw_all flash] as the differences will be profound because of the packing regardless if the flash does complete or not.

It's only worth comparing the original fw_all.bin with the 14 dump obtained after the original fw_all has been flashed in my [uneducated] opinion. Best wait until kunix is back on-line, but if you want to do something now flash rgn made with original boot and original fw_all, then dump 14 again using patched boot.bin>rgn method.

Compare original fw_all.bin with new 14.bin, except for the trailing FFs in 14.bin they should be the same, if not then the flash didn't complete for sure i would think.

@kunix
Yes, much as i thought. Just one point though, SF posted this:

Originally Posted by smokefree

........
2. I then dump rgn14 as described and compare it in a hex editor to the packed fw_all.bin file. Correct?

That's what i meant is pointless because the packed file will always differ when compared to the dumped 14. It seems logical to me only by comparing 14 to the original [or unpacked] fw_all can there be a valid comparison. So in essence, whether the flash was done with original or packed fw_all, the compare of the dumped 14 has to be to the full [not packed] fw_all, is that right?.

@both
I'd have thought there should be no difference other that the empty padding at the end of the 14 dump. In a 265W i've removed the extraneous FFs and the fw_all and 14 bins are then identical in hex and hash check. Why should a zumo 220 be different? A fault?