Quote Originally Posted by diversola View Post
I solved the problem but the computer still doesn't recognize it.
You're likely just intending to use the workaround of loading from the SD card as i suggested you could do.... which means it isn't "solved".
So you should write that you still have the actual original problem BECAUSE the computer still doesn't recognize it.

And I didn't mean to ask how to patch garmin.
We simply discerned that it was your intention to patch it, we've not said you asked specifically. We merely explained how and why it could be done together with a firmware upgrade to V4.60. It was you who realized the SD method of the patch was similar to the SD workaround used for the loss of USB communication with the PC due to a hardware failure.

I thought this was some other method.
Really? It's not 'some other method' as explained above. In fact the SD Patch Kits were first developed in this very forum many years ago as a result of users not being able to use a patched GCD fw file due to Garmin introducing GVS protection into firmware which checks the Gupdate.gcd's Verification of Signature to disallow loading a GCD file that's been manipulated (modified in any way, not just patched). At the same time, Garmin made preboot mode far more difficult for casual users to activate on modern devices which meant that they were unable to easily load an RGN file using Updater.exe, which was the standby method for loading modified fw for many years. Using SD with del, copy, ergn, rrgn, xrgn etc. text cmds was made public (again in this forum) in late 2011 and the SD Patch Kit method was later adapted from that knowledge, several years after that in fact, but as a direct result of and building upon the valuable knowledge gained from experiments detailed in the earlier thread: [Only registered and activated users can see links. ].

I thought Garmin cur 3 could help me. You said it wouldn't and that it could be solved in another way via SD card.
(i) The reason i said Cure fw wouldn't help you is because your device was never soft-bricked. I also said in Post #10 that it would be "worse than useless and would be counter-productive quite frankly". Let me explain fully why, if not for you for other readers. Assume you had managed to load a cure fw as a BIN file to region 14 using SD txt cmd. That means that the device would then stick on the logo splash screen BEFORE it could load any essential files during boot-up (cure fw's very design purpose in fact, so that Mass Storage Mode can be re-enabled). The device looks for an SD card AFTER 'loading maps' appears on the device screen, i.e. after essential files are loaded during booting. So you'd now have a device unable to access preboot because of a board fault and unable to read from SD card because it's got cure fw in rgn14, so no available method to re-flash it. It'd be effectively useless and only good for parts other than the PCB.

(ii) To be perfectly clear, I didn't say it could be 'solved'. The SD method was suggested as a workaround for updating, not a solution for the actual problem of loss of PC communication. Your device's hardware failure remains.

I am satisfied with what I have done.
That's good.

However this thread can now best serve as a reference point for users trying to get an understanding of how SD can be used for flashing regions/file copying or overwriting and importantly for pointing out the real dangers of using manipulated fw (whether that's cured, patched, hybrid combined or any other modification) without comprehending the potentially fatal consequences for a device should there be mistakes made.