Almost (really) bricked my N66U. Very interesting experience...

[CaptnDanLKW]

I've been a long time reader of these forums and merlin user since I got my N66U a long time ago. Prior to that I had a Linksys/Cisco WRTN320 running dd-wrt for about 3 years. I've upgraded hundreds of times, corrupted it dozens, converted it to an E2000, had to serial recover countless times and even had to make and solder a JTAG cable to the header. I know I wore out the flash chip, which is why I purchased the N66U.

So when I went through my normal Merlin upgrade process, which was to interrupt boot, clear the nvram using the CFE miniweb interface, and upload the latest at it would never get beyond the CFE (192.168.1.1 responding with TTL=100) I knew where it was stuck.

I cracked open the case, connected my trusty USB-TTL cable to the header and sure enough, it was at the CFE> prompt with the usual error about a bad image. I tried multiple times to upload the new merlin code, then the current asus version, then an older version using the recovery tool method and the flash command and a tftp server. They would all hang at:
Write kernel and filesystem binary to FLASH
Programming...

In my experience this usually doesn’t take too long, 5-10 minutes seemed typical. I was waiting 30-45 minutes before giving up and trying again.
Finally I just let it sit there. Around the 90 minute mark, literally about 1 minute before I was going to give up it finished.

So, after my long winded story, does anyone have a theory why it took so long? Bad areas in the flash causing 'retries'? Major code change that had to zero out every byte? Do you think the next flash will take that long?

Thanks for reading!

 

[RMerlin]

I've been a long time reader of these forums and merlin user since I got my N66U a long time ago. Prior to that I had a Linksys/Cisco WRTN320 running dd-wrt for about 3 years. I've upgraded hundreds of times, corrupted it dozens, converted it to an E2000, had to serial recover countless times and even had to make and solder a JTAG cable to the header. I know I wore out the flash chip, which is why I purchased the N66U.

So when I went through my normal Merlin upgrade process, which was to interrupt boot, clear the nvram using the CFE miniweb interface, and upload the latest at it would never get beyond the CFE (192.168.1.1 responding with TTL=100) I knew where it was stuck.

I cracked open the case, connected my trusty USB-TTL cable to the header and sure enough, it was at the CFE> prompt with the usual error about a bad image. I tried multiple times to upload the new merlin code, then the current asus version, then an older version using the recovery tool method and the flash command and a tftp server. They would all hang at:
Write kernel and filesystem binary to FLASH
Programming...

In my experience this usually doesn’t take too long, 5-10 minutes seemed typical. I was waiting 30-45 minutes before giving up and trying again.
Finally I just let it sit there. Around the 90 minute mark, literally about 1 minute before I was going to give up it finished.

So, after my long winded story, does anyone have a theory why it took so long? Bad areas in the flash causing 'retries'? Major code change that had to zero out every byte? Do you think the next flash will take that long?

Thanks for reading!

There are a few posts in the Asuswrt-N forum here about the fact that the RT-N66U (and the RT-N16) can be quite long to flash. The reasons are that:

a) The firmware is huge (25 MB versus your average 2-5 MB firmware on older routers)
b) the flash type on these two models is still the same slow flash as used in those older routers

So, a flash time of 20-40 minutes in recovery mode is fairly typical for these two models while in recovery mode (no idea however why flashing in recovery mode is always much slower than in regular operational mode). Newer models starting with the AC66U use much faster NAND.

 

[CaptnDanLKW]

Thanks for the quick response.

The hope is my story helps anyone who is used to waiting a long time for the router to come back online after a 'recovery mode' upgrade to wait longer... a lot longer (90 minutes!) and not freak out like I did.

 

[ikomrad]

I've been a long time reader of these forums and merlin user since I got my N66U a long time ago. Prior to that I had a Linksys/Cisco WRTN320 running dd-wrt for about 3 years. I've upgraded hundreds of times, corrupted it dozens, converted it to an E2000, had to serial recover countless times and even had to make and solder a JTAG cable to the header. I know I wore out the flash chip, which is why I purchased the N66U.

So when I went through my normal Merlin upgrade process, which was to interrupt boot, clear the nvram using the CFE miniweb interface, and upload the latest at it would never get beyond the CFE (192.168.1.1 responding with TTL=100) I knew where it was stuck.

I cracked open the case, connected my trusty USB-TTL cable to the header and sure enough, it was at the CFE> prompt with the usual error about a bad image. I tried multiple times to upload the new merlin code, then the current asus version, then an older version using the recovery tool method and the flash command and a tftp server. They would all hang at:
Write kernel and filesystem binary to FLASH
Programming...

In my experience this usually doesn’t take too long, 5-10 minutes seemed typical. I was waiting 30-45 minutes before giving up and trying again.
Finally I just let it sit there. Around the 90 minute mark, literally about 1 minute before I was going to give up it finished.

So, after my long winded story, does anyone have a theory why it took so long? Bad areas in the flash causing 'retries'? Major code change that had to zero out every byte? Do you think the next flash will take that long?

Thanks for reading!

Where did you get your USB-TTL cable? I have never heard of that kind of cable before. Amazon?

 

[martinr]

Where did you get your USB-TTL cable? I have never heard of that kind of cable before. Amazon?

For starters, you look at mouser electronics' range. I bought this one

http://www.mouser.co.uk/Search/m_Pr...=sGAEpiMZZMsgIz308WEU04nfkDx8j72Obf0AB+49AG8=


from them when making up a lead to connect to a pre-EOBD automobile ECU.