RN102 unresponsive after initiating FW update from 6.10.6 to 6.10.7

Will it not respond to the power button for turning it on or off?  Will it turn off if you press and hold the button?  Do you regularly re-boot the NAS, or was the re-boot  the first in a long time?  Is the Ethernet LED illuminated when it's on, or when it's off (but plugged in)?

It's beginning to sound like you may have a problem with the +3.3VSB in the unit, and possibly other voltages.  The answers to these questions will help determine just how likely that is.

Ever since the attempted OS update the unit does not respond to the POWER button no matter how long you depress it.

Same with power on. Ever since the attempted update, as soon as power is applied to the unit it powers up without

touching the POWER button.

Re: Ethernet LED
>>Excellent suggestion! I completely forgot to look, and it is a useful datapoint in troubleshooting.
>>It starts flashing a second after power is applied to the unit.
>>HOWEVER, I did mention that when the unit is plugged in and connected to the router
>>it seems able to negotiate operation of the cable connection at 1Gbps, and that's a physical layer/hardware
>>sort of thing, right?  And that would require stable power to the Ethernet circuitry/chip.

Re: Is the Ethernet LED illuminated when it's on, or when it's off (but plugged in)?
>>The plugged in and power off state is not attainable.
>>Unit powers up as soon as power is applied.
>>In case you were gonna ask, when disks are installed they spin up and become ready
>>as indicated by a test point on the Hitachi drives.

Re: +3.3VSB [...] and possibly other voltages.
>>My area of expertise, and I have the technology to check.
>>I have checked the external power supply and it is stable & clean under all load conditions.
>>HOWEVER, the fact that I am able to enter the boot menu (unit recognizes that RESET button is
>>being held on during power up) and cycle through boot options (unit recognizes operation of the

>>BACKUP button) would seem to mean power is probably not the issue.
>>Granted, the result of selecting any of the boot options results in a rapidly (5 per second following

>>a 6 second pause) flashing POWER LED and that means someone is running some code
>>somewhere, right?
>>Having said all that, I will measure everything I can.

Re: [...] or was the re-boot the first in a long time?
>>Unit being power cycled / rebooted is rare. UPS battery can keep the unit, and related equipment,
>>up for 90 minutes, and extended power outages are rare. I did notice that uptime was 48 days prior
>>to OS update.

Power-on with the button is pretty much independent of anything else.  It has an input for commanded power off and WoL power-on, but it's hard to figure how a fault in those could keep the button from working.  It is powered by the +3.3VSB (created internal to the NAS from the external 12V), but so is the Ethernet (to support WoL).  The 3.3VSB is on whether the unit is "off" or not.

Given the Ethernet seems to be working (though no address assigned because the processor never negotiates one), that probably eliminates the 3.3VSB as the cause.  It may be something else in the power-on circuit that is causing the problem with the power on/off, something that may have happened some time ago but was not detected because the NAS was never powered off.

I think your issue with the button and the NAS not booting may be separate issues.  I think you should at least assume that for now.

Given it doesn't even show up in RAIDar with no drives, the next thing I can think of is it's a UBOOT issue.  A USB recovery is supposed to fix that, though I've seen instances posted here where it didn't seem to.  Still, it shouldn't hurt even if it's not the fix.  Given you can get to and go through the boot options, I don't think it's a CPU or RAM issue (not that either is repairable).

But the memory test also relies on UBOOT to at least get started.  So I don't think you're ready to call it a brick yet.

Sandshark,
If you haven't already, check out my latest post of bizarre behavior here:

Re: USB Recovery and boot menu > memory test with reference to OS updates and making brick

Sandshark,

I reread your statement and wanted to clarify a point.

Re: "But the memory test also relies on UBOOT to at least get started."

The thing is, I am uncertain that memory test actually started as the rapidly flashing

POWER LED is used as an indication of many different events (unfortunately)

and may not mean memory test has started but that some error/event has occurred

not directly related to memory test.

---

btwixt wrote:

Sandshark,

I reread your statement and wanted to clarify a point.

 

Re: "But the memory test also relies on UBOOT to at least get started."

 

The thing is, I am uncertain that memory test actually started as the rapidly flashing

POWER LED is used as an indication of many different events (unfortunately)

and may not mean memory test has started but that some error/event has occurred

not directly related to memory test.

---

I think Sandshark is agreeing with you here - he's saying that the memory test relies on UBOOT, and if that isn't functioning, then the memory test might not have started.

Yes, I am saying that both the memory test and normal booting could be adversely affected by a corrupted UBOOT.  A USB recovery is what I believe you should try next.

Re: USB recovery

I have tried about two dozen times.

I've tried with about a dozen different flash drives.

Each try went as follows:

Insert flash drive, hold the BACKUP button, and apply power (unit is stuck in the state where it powers on without touching the power button.)

The POWER and BACKUP LED start flashing rapidly and there are a couple of bursts of activity indicated by the flash drive LED.

I have not yet released the BACKUP button (instructions say to hold it in for a full 30 seconds.)

The flash drive activity ends in about 6 seconds.

The POWER and BACKUP LED have been flashing rapidly since power application, and continue to flash.

30 seconds after power application I release the BACKUP button.

The POWER & BACKUP LEDs continue to flash.

The minimum amount of time until I remove power and try again has been 20 minutes.

(Is that long enough?)

A few attempts left power applied, POWER & BACKUP LEDs flashing madly away the whole time, for over 4 hours.

---

btwixt wrote:
Folks, I'm willing to try anything to resurrect this unit.
What are the chances of acquiring the necessary software / hardware documentation, including any debugging fixture details, to fix this thing?

---

There isn't really much that can be repaired.  The chips aren't socketed (both memory and the CPU are soldered to the system board).

One easy thing - we never completely ruled out a power issue.  You could try connecting a power brick from one of the replacements you purchased, and see if the system boots normally.  Best to use a spare disk of course.

In reply to StephenB:

Re: There isn't really much that can be repaired.
>With respect, Steven:
>This is, and always has been, a matter of will instead of capability.
>There are many surface-mount-capable repair facilities in the US.
>A local (to me) facility is even FAA and MIL-STD-2110/2111 approved.
>I doubt the Marvel chip is at fault (but even if it were, it is replaceable)
>and that leaves all the relatively easy stuff.
>The REAL obstacle would be getting hardware documentation and

>possibly sourcing parts.  And that would be a matter of will also.

Question about Marvell ARM chip:

Which one, exact part number please, does this unit use?

I would like to know if it is an SOC device with flash memory.

Re: power issue
>Tested, measured (both inside & out of failed unit), and substituted.
>I actually have four supplies to "play" with. All are 90W to 120W units,
>and very quiet from an electrical noise standpoint.

I am waiting for a reply on another post regarding testing the only thing
I haven't tested, the serial port.
If the serial port yields nothing, I am off in search of documentation.

FULL DISCLOSURE:
At some point while inspecting the insides of the failed unit I discovered
the battery was at 1.98V. I used a fixture to keep battery voltage applied
to the board while I replaced the battery. Even though the original battery
was in this poor condition during the OS update the RN102 was always on a UPS
and never lost power.

---

btwixt wrote:

In reply to StephenB:

Re: There isn't really much that can be repaired.
>With respect, Steven:
>This is, and always has been, a matter of will instead of capability.

 

---

Not convinced that the cost of repair is worth what you'd get.  We're talking about a 9 year old entry-level NAS.  But if you want to give it a try, of course you can.

---

btwixt wrote:

 

Question about Marvell ARM chip:

Which one, exact part number please, does this unit use?

I would like to know if it is an SOC device with flash memory.

 

---

Netgear doesn't provide the hardware documentation you are looking for - and I don't work for them, and have no access to internal documentation.

Googling suggests it is an 88F6710.  But it's probably best if you look at the system board and confirm this. 

Few users have the equipment to de-solder and solder ball grid array parts.  Many of the parts cannot be purchased in small quantities.  And just figuring out what part(s) need to replaced is going to be quite a task without a schematic.  The board most likely won't hold up to just replacing things until it's fixed. 

Even Netgear doesn't repair them.

So, at least for most, it is a matter of capability, not will.  If you have the appropriate equipment and skills needed, then go for it and please share whatever you learn with the forum.

Thanks for all the input!

Yeah, the time & resources I spend messing with the failed unit are just part of my hobby.

Some people like picture puzzles or crosswords.  I like resurrecting broken machines.

Well folks, it's been fun.  Guess we'll leave this issue unresolved.

The unit died using the online update, causes unknown.

(Makes me wonder if the manual update would have been successful.)

If I learn more I'll post it, of course.