Can you access the ec console directly via servod?

From chromeos6-row4-rack4-labstation1

localhost ~ # dut-control ec_uart_pty
Connection refused

Can you have chrome stop assign me an enguarde?

+ gkling, + matt for visibility

 nsanders@ You have a Enguarde ready for pickup at Chromestop. 

Looks like chromestop doesn't have any enguarde with servo headers. Are you in 2081? Can you take a failed enguarde to someone on the HW team familiar with servo operation to check it out? You could drop one at my desk if you like, but it's probably not convinient to you.

Yes, I am in 2081. Please let me know where to drop it off.

rsabanga@rsabanga-glaptop0:~$ chromiumos/src/third_party/autotest/files/check_servo_v4.py -b enguarde -d chromeos6-row4-rack4-host5 -e chromeos6-row4-rack4-labstation1 -s C1612060065
checking chromeos6-row4-rack4-host5 --------- START
checking warm_reset: FAILED - warm_reset is stuck: on
         Try resetting the EC on the DUT (3 finger salute)
checking lid_open: PASSED
checking pwr_button: FAILED - pwr_button is stuck: press
         Try resetting the EC on the DUT (3 finger salute)
checking EC connection: FAILED - check uServo connection (Setting 'ec_uart_cmd' to 'version' :: Timeout waiting for response.)
checking usbkey: PASSED
checking chromeos6-row4-rack4-host5 --------- FINISHED
rsabanga@rsabanga-glaptop0:~$

chromeos6-row4-rack4-host5     Check ribbon cable: 'pwr_button' is stuck;  logs >>> https://paste.googleplex.com/6051891590987776

Can you bring a failed device to Willis at 
US-MTV-2081-1-1K2A and go though checking the ec connection together?

Hey all, we are having series issues with enguarde failing and not being able to recover.  We were recovering from R59.  0X5A and 0X5B, any connection to this error?

Not likely, this is an issue with the servo debug header and internal Google test environment. So you can probably file a different bug on the partner tracker.
https://www.chromium.org/chromium-os/servo

I noticed today the warm_reset is not in Servo overlay file anymore, instead is cold_reset. Can someone confirm? 

> Can you bring a failed device to Willis at 
> US-MTV-2081-1-1K2A and go though checking the ec connection together?

Ai ya.  The supply of enguarde DUTs is critically low.  That's
a separate issue, except that we can't afford to take any of
them out of service for very long, unless we're willing for the
canary to just quit testing...

As for the underlying symptom:  Servo code in the test lab doesn't
require warm_reset to be present, let alone working.  Whatever
check_servo_v4.py, it needs to be redone to do what 'servo-stat'
does.  Better still, drop that script in favor of 'servo-stat':
The 'servo-stat' script tests what's actually important; so does
'repair_test'.  If servo-stat and repair_test are passing, but
check_servo_v4 fails, it's not a bug that matters.

Issue 776568 has been merged into this issue.

Can you bring a failed device to Willis at 
US-MTV-2081-1-1K2A and go though checking the ec connection together?

There's nothing actionable here until that happens.

Will do. Thanks!

I've dropped an Enguarde (C058693) and power supply on Willis' desk. Let me know if you need anything else and when I can pick it back up.

Was this working previously?  Is it the only one with this issue?

It appears that none of the servo header resistors have been stuffed.  The header itself seems to be installed correctly.

However, I don't have access to a schematic for Enguarde and the reference designators are not the same as Rambi, so it is not simple to verify this.  I can reverse engineer it if this is critical.

Does this need repair, or just diagnosis?

> No repair - we're trying to make this board work with servo v4
> in the test lab. Nick, correct me if I'm wrong, but I think the
> specific need here is to see if the EC console can work via servo v4.

IIUC, the reason that the EC console doesn't work is because the
devices need rework before they can be used with any servo.  In
practical terms, I think that means we need to send the units for
the rework (at minimum, stuff that resistor).

Yes, these devices need mlb rework before they will function with any servo. The servo header and supporting parts weren't stuffed correctly.

How can we get the rework done? Should I send the Enguardes we have to Ngoc's team and ask for mlb rework?

OK, in that case you can send the units to Ngoc and ask her to stuff the following components:

R499, R545, R540, R538, R208, R535, R524, R216, R505, R536 should be 0 ohm resistors

R544, R506, and R537 should be stuffed with 10.0 ohm resistors

R207 and R199 should be stuffed with 4.7K resistors

I can ask Lily to do that with this unit as well, or you can take it back and have Ngoc do it.

+mwortham@

Matt, is there something we should do to improve this flow in future?

gkling@ has reached out to me about this. He is going to create a ticket for my team to pickup the devices from the auto test lab, and deliver them (along with our stock at Casey) to Ngoc to be reworked. If you would like anything additional to be done please let us know. 

Nick, do you think the devices we already have deployed on v3 need this rework? 

re #27
If the machines are currently functioning with v3, they already have the rework. This issue is unrelated to servo v3/v4.