Electronics > Microcontrollers

Intel Atom C2000 Failures

(1/13) > >>

bson:
Does anyone know more about the Atom C2000 family failures?  In the errata sheet, Intel states:

--- Quote ---AVR54. System May Experience Inability to Boot or May Cease Operation
Problem: The SoC LPC_CLKOUT0 and/or LPC_CLKOUT1 signals (Low Pin Count bus clock
outputs) may stop functioning.
Implication: If the LPC clock(s) stop functioning the system will no longer be able to boot.
Workaround: A platform level change has been identified and may be implemented as a workaround
for this erratum.
Status: For the steppings affected, see Table 1, “Errata Summary Table” on page 9.

--- End quote ---

The LPC is a PCI-to-ISA bridge controller and is one of the two supported BIOS boot locations; the C2000 can either boot from SPI (default) or LPC/ISA (set via external sense pins at powerup).  This is fixed in a stepping, and curiously the "fix" consists of eliminating the ability of muxing the LPC bus pins with GPIO - they no longer become software selectable.  This is pretty much ALL I've been able to find on the subject.  There's a workaround which consists of adding an external 100 ohm resistor, but it's not clear what pins this is added to.  It's added across two pads on a connector on some Synology NAS units, so it's not an output current limiter but almost certainly a stiff pullup or pulldown.  This leads me to suspect it really goes on a configuration sense pin.  Intel hasn't made their "platform level change" public.  Tracing it out on a board is kind of hard since the SoC is a large BGA package that would need to be desoldered.

Does anyone know more about this?  Like, for example, where the resistor is added - in particular is it added to the LPC clock outputs, or to the sense inputs? 

It's also not clear if the clock output actually fails, or this is merely a convenient symptom any engineer with a scope can identify.  (The two LPC clocks are only 25MHz.)  Some possible root causes I can think of are:

1. The sense input pullup is underdimensioned and fails, resulting in the CPU trying to fetch boot firmware from SPI.
2. The sense configures it for LPC boot while the pins are reset to GPIO, resulting in duplicate pin drivers that short out internally.
3. 1+2 -  multiple sense inputs with slightly different thresholds result in inconsistent pin configuration with both pin drivers enabled.
4. The clock pin output driver actually dies.

#4 sounds simple and straightforward, but somewhat implausible to me.  This isn't Intel's first rodeo, and besides how would an external resistor help with this?

Here's the C2000 family datasheet:
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-c2000-microserver-datasheet.pdf

Errata:
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/atom-c2000-family-spec-update.pdf

amyk:
Some more info here: https://www.mail-archive.com/list@lists.pfsense.org/msg10553.html

Monkeh:

--- Quote from: bson on September 27, 2017, 09:12:48 pm ---#4 sounds simple and straightforward, but somewhat implausible to me.  This isn't Intel's first rodeo, and besides how would an external resistor help with this?

--- End quote ---

From what I've been able to gather, this is exactly what's happening - the resistor is connecting a different clock pin to the LPC bus. This is not the first time Intel has had consistent aging failures like this.

bernroth:
I made a post some time ago:

https://supportforums.cisco.com/t5/firewalling/clock-signal-repair-pictures-isr4300-asa-isr4400/m-p/3088505/highlight/false?attachment-id=107384

The fix applied by Cisco is by putting a 110 ohm pull-up resistor from either LPC_CLKOUT0 or LPC_CLKOUT1 to +3.3V

I don't want to talk about their repair quality  |O

Currently I am trying to fix another Cisco router. I found the signals LPC_CLKOUT0 and LPC_CLKOUT1.

Does anyone know which one of these pins requires the pull-up?
Maybe I'll just put two pull-up resistors :)

hfiennes:
Ok, a very late reply but my Synology DS415+ box died, and the 100 ohm resistor (across pins 1 & 6 of a 12 pin, 2mm header) made it work again.

It's all back together now so I can't really verify this theory, but do we know *how* the clock output dies? The register article quotes intel as saying "a degradation of a circuit element under high use conditions at a rate higher than Intel’s quality goals after multiple years of service.".

https://www.theregister.co.uk/2017/02/06/cisco_intel_decline_to_link_product_warning_to_faulty_chip/

Could the issue be the PFET in the clock driver dying? If that was the case, a strong pull-up on the clock line - meaning only the NFET needs to be functional to get a clock out of the pin - would indeed solve the issue. This seems to square with the Cisco fix too - it's just a strong pull-up.

(it also means that there's 33mA being sunk by the driver 50% of the time, which makes me fear for the longevity of the fix - and whether something like the smart pull-up on an I2C FM+ bus would stress the D2000 less)

Navigation

[0] Message Index

[#] Next page