Hey, all,

I've got a Trendnet/Trendware TEW-411BRPplus unit (BCM4712/4MB Flash/16MB RAM/ADMtek 6996 switch) that I loaded the latest OpenWRT experimental release (squashfs version) onto.  I was able to load OpenWRT onto the router through the Trendnet stock firmware's web interface.  Long story short (I can post details later if anyone's interested), I fscked something either in the startup configs and/or in NVRAM and I can't communicate with the unit any longer (GPIO for this unit must be unknown...reset switch depression does NOT trigger failsafe mode), though I know it is still booting successfully.

I made myself a custom OpenWRT image with /etc/preinit set to force failsafe regardless of the status of the reset button, and tried to load it onto the unit through CFE's TFTP server (boot_wait is enabled).  The unit accepts the full file transfer every single time I try it, but after it receives the new firmware image, it doesn't appear to try to write the contents to flash memory...it just continues on its merry way booting the old one!

So I tried to take the original TEW-411BRPplus firmware and load it on through CFE TFTP.  But it did the same thing!!  Upload is successful, yet after the transfer is over, it just boots the old firmware and doesn't appear to try and write to flash.

My guess is that CFE is rejecting the firmware image for some reason (though there is no serial header on the board that I can see, so I'm not sure how to discover what the problem is).  The Trendnet tech that I've been speaking to doesn't have any idea why, and has supplied me with a couple different firmware images to try already.  As far as I can tell, assuming this particular CFE version is not miscalculating the CRC (that would suck), the only location of the firmware header that CFE would check (bytes 13-16, version information and "flags") is identical on all firmware images received or built to-date, both Trendnet and OpenWRT (contents are hex 00 00 01 00)..

Has anyone else seen this kind of behavior before on any other BCM-based devices?  Any suggestions as to what else I might try?

Thanks, everyone.  And special thanks to all of the developers actively involved with OpenWRT...I love it so far.

-- Nathan

Some models require a specific filename, for example "code.bin".

Ooooooh...that very well could be the problem!  I'll give that specific name a try in a bit, here...

Anybody have a list of common firmware names that might be required by certain models?

I don't imagine I'll be able to discover what name mine is expecting (if indeed that is the problem) without getting the CFE code/config that Trendnet used to build the one that's running on this model, huh?

BTW, just before I came back and saw your reply, I decided to try the "shorting pins 15-16" trick to see if I could get it in a state where I could play with it a bit.  I must've found the right pins because rather than just sending me 3-4 ping responses on bootup, it kept going.  Here's an interesting fact: when it thinks its firmware is corrupt and I TFTP it one of the ones I've tried in the past, it just continues to sit there and ping away.  It's pretty obvious that it doesn't like the firmware image(s) I'm sending it now; it thinks there is no main firmware (so it can't fallback to anything) and doesn't like what I just sent it, so it continues to accept TFTP connections for different firmware.  I sent it 3 or 4 in a row without rebooting.

-- Nathan

Welp, code.bin didn't work.  Neither did code.trx, linux.bin, linux.trx, piggy (hey, it's about the ony string I saw in the file...), piggy.bin, piggy.trx...

Maybe I'll grab a CFE source tree from someplace and peruse it a bit...

Thanks,

-- Nathan

Ahhhhh, screw it...I just really messed things up now...

In my zealousness to find a working fix, I decided that the next thing to try would be to short pins 2-3 on the Intel EEPROM, just to see if any of the changes I had made to NVRAM is what caused the problem to begin with.  The first time I tried it, it did seem to keep the unit from booting up (observing the LEDs), but CFE also stopped responding to ethernet communication.  A reboot showed that it was still working "normally" at that time, though.  The second time I tried it, it stopped responding again, and it seems it also somehow managed to corrupt CFE itself.  Ever since then, the only thing that happens now upon power-up is that the power light blinks.  The ethernet ports NEVER initialize now, not even for a TFTP upload.

Sighhhhhh...

Guess its time to read up on JTAG now...

Thanks, anyway,

-- Nathan

Well, guess what?

I built myself a JTAG cable, soldered a JTAG header onto the board, and here's what I get:

[root@sawtooth Desktop]# ./wrt54g -backup:nvram

====================================
WRT54G EJTAG DeBrick Utility v2.2
====================================

Probing bus...
CHIP ID: 00010100011100010010000101111111 (1471217F)
*** Found a Broadcom BCM4712 Rev 1 chip ***

Enabling Memory Writes...Done

Configuring Memory...Done

Resetting Processor...
Done


*** You Selected to Backup the NVRAM.BIN ***
=========================
Backup Routine Started
=========================

Saving NVRAM.BIN.SAVED_20050505_160932 to Disk...
[  0% Backed Up]   1fff0000: 00000000 00000000 00000000 00000000
[  0% Backed Up]   1fff0010: 00000000 00000000 00000000 00000000
[  0% Backed Up]   1fff0020: 00000000 00000000 00000000 00000000

Mmmm...all zeros.  I looked at the resulting file, and found that it was ALL zeros.  Totally worthless.  Okay, so I'll try backing up CFE.  Same results: file is full of nulls.

Is my flash chip just...empty now?!  Let's try putting some data on there and see if we can read it back:

[root@sawtooth Desktop]# dd if=/dev/urandom of=./NVRAM.BIN bs=1 count=65536
65536+0 records in
65536+0 records out
[root@sawtooth Desktop]# ./wrt54g -flash:nvram /noerase

====================================
WRT54G EJTAG DeBrick Utility v2.2
====================================

Probing bus...
CHIP ID: 00010100011100010010000101111111 (1471217F)
*** Found a Broadcom BCM4712 Rev 1 chip ***

Enabling Memory Writes...Done

Configuring Memory...Done

Resetting Processor...
Done


*** You Selected to Flash the NVRAM.BIN ***
=========================
Flashing Routine Started
=========================
Probing for Intel Flash...DMA Read Addr = 1fc00000  Data = (00000000)ERROR ON READ
ID:(00000000)... *** Unable to Locate Intel Flash Chip ***

???  What does this mean?   Did I zap/ruin my flash chip when I was shorting pins?  Is there any hope left?

-- Nathan

Try unplugging the power before initiating each JTAG command operation if you haven't.

Depending on type of the flash chip and what pins you shorted/until when you shorted, you can completely erase the whole flash.

I don't think that happens often, though, I've heard some people permanently damaged the flash chip by shorting pins.  (Yes, I believe them.)

Thanks for the response, mtakahar.

I have.  It doesn't help.

How likely is it that I physically damaged the flash?  Anybody else seen these symptoms?

-- Nathan

Perhaps someone ought to add to the faqs somewhere the details for backing up the complete flash. (Will just dd do it?), and encouraging people to get a backup _before_ they realise they've lost the lot.

Hopefully, this should mean that in the event of totally erasing the flash, CFE can still be restored via JTAG.

Well, I agree that that kind of information would be good to have in general, but as far as this specific situation goes, it wouldn't do me much good.  Even if I had made a backup, I couldn't make use of it since the flash/JTAG interface is not accepting anything I throw at it.

I'm just hoping that there happens to be some slight difference between this Trendnet and the Linksys models that the wrt54g EJTAG program does not take into account and doesn't know how to work around.  At least then it is a problem with a possible fix, even if its one that cannot be immediately solved.  If the flash chip is truly dead, I might as well toss this thing in the garbage.  It was a brand new unit, too. :-(

If I have wired up everything correctly according to HairyDairyMaid's guide, and if a couple of the pins were "switched" on this board compared to the Linksys boards, would it be possible to correctly identify and initialize the JTAG interface on the Broadcom CPU but NOT be able to read or write to the flash?  Or is the fact that I can talk to the 4712 a sign that the JTAG is wired and working correctly?

-- Nathan

I think it's unlikely that they have switched some JTAG pins from Broadcom's reference design, but HDM's utility and cable design are based on assumptions the way things are in WRTs.  It may be that your flash chip is different and slightly different DMA mode need to be used, may be some of the pin 2,4,6,8,10,12 are not grounded, may be because of voltage mismatch between your router and your PC, or may be something else.

My cable has these JTAG pins connected altogether and also the pin 18 to 25 on the parallel port side.

Actually, I failed to mention in past posts that I actually struggled initially to even get the JTAG cable to work precisely because pins 2, 4, 6, 8, 10, and 12 are not connected to anything at all on this particular board (they're not grounded).  I was getting back all sorts of random garbage values for the CHIP ID until I took a close look at those pins and saw that there were no traces to them from anywhere; they're just simply holes on the board.  So I ended up grounding pins 20 and 25 on the parallel port to the metal chassis around the ethernet ports just to see if that would do the trick, and *schwooongg!* it was able to correctly identify the Broadcom CPU after that.

So I'm pretty sure that grounding is not my problem right now.

If it is NOT my flash chip that is dead, then I would think that your first guess (different DMA mode) is the most likely possibility.  However, I have an Intel 4MB Flash chip on here (TE28F320-J3C110), which I understand is the 8MB chip's little brother.  I'd be surprised if HDM's EJTAG utility wouldn't work with this chip out-of-the-box (besides, don't the later versions of the WRT54Gs now use Intel chips similar to these instead of the AMD ones used in earlier versions?).

-- Nathan

FYI - there's an updated copy of the jtag debrick utility here:
http://openwrt.org/downloads/debrick.tar.bz2

I'm back.

No more progress on this yet...I actually had found that file at that location the day you posted this message (I learned of it by reading the IRC chat logs ).  It behaves slightly differently...I get the DMA "ERROR ON READ" for both the read AND write functions of wrt54g with the v3.0 version.

I've now tried this on two different computers with the exact same results on both (and with both versions of the wrt54g utility).  I doubt that my cable is bad...otherwise I would expect that it wouldn't be able to properly identify the CPU and perform all of the initialization functions.  Thus, I can only conclude, unless somebody else has got a better explanation, that I managed to wreck my flash chip (physically) by shorting pins.

I'm kind-of surprised that this hasn't happened to more people.  Seems to me (based on my experience...hindsight being 20/20 and all) that doing the pin-shorting trick is a dangerous proposition, and that as time-consuming a process it may be, people who want to debrick their router should start FIRST by soldering on a JTAG header.  For me, this was, sadly, an expensive lesson to learn.

-- Nathan

For anyone who might run across this thread while searching through the forums, this problem has been solved.  Well, sort of.  I managed to fix the flash and get the JTAG working, but CFE still doesn't flash data TFTPd to it during boot_wait, which is annoying because if I fnork my router up again, I have to wait the 2+ hours for the firmware upload via JTAG to complete.

-- Nathan

Hello NathanA, I had the same problem!!! SAME ROUTER! Can you help me to save my router from the trash? Plase! Plase!! Please!!!
You can contact me at:

glaucocmotta@yahoo.com.br