Who is the correct owner for this?

The optimal current owner is likely @aashutoshk  to attach logs for chromeos-firmwareupdate --mode=factory.

Not clear why the ChromeOS version is not included, so please include the particular build you observed the failure on.

> The device goes into bad state

what are some properties of the state?

Here is the missing and requested information, 
1) Cyan device was running  R69-10800.0.0 (69.0.3464.0) when it went into a bad state.
2) The machine does not boot up, so I cannot collect any logs.  
3) Also, I did not make a note of the firmware installed on the device ( I guess it was *.57.100) and the firmware it was trying to upgrade. 
End goal was  to upgrade the device to ChromeOS-firmware-R46-7287.57.178 firmware. 

what are some properties of the state?
>> 1) Device is not booting (power led off). 
2) After running chromeos-firmwareupdate --mode=factory, the output mentioned something in the line of "command failed, do not power cycle the device," but I accidentally power cycled it while trying to connect to the servod. 
3) I was able to run servod fine, but  EC-console and CPU-console were not working. 
Let me know if you need any more info. 

I don't think R69-10800.0.0 contains ChromeOS-firmware-R46-7287.57.178, i.e. you would not have accomplished your end goal had the intitial chromeos-firmwareupdate been successful, but let's circle back to that later.

>> 1) Device is not booting (power led off). 

So, no display activity? (if it it stuck at a recovery screen press tab and record the debug info).  We will likely need to flash via servo if there's no display activity.

> 3) I was able to run servod fine, but  EC-console and CPU-console were not working.

describe not working: for example, do you get a prompt when you open the ec console? please start servod with the debug flag and attach logs.

So, no display activity? (if it stuck at a recovery screen press tab and record the debug info).  We will likely need to flash via servo if there's no display activity.
>> Nothing at all on screen or led light. It is a paperweight. 

We will likely need to flash via servo if there's no display activity.
>> I have tried the  commands under "Flashing coreboot and EC" heading from Care and Feeding Notes for Cyan doc

describe not working: for example, do you get a prompt when you open the ec console? please start servod with the debug flag and attach logs.
Yes, I got a prompt, but there was no activity on the EC console, and it did not register any input.  

I don't see servod logs attached.

In addition to servod logs, please attach the output of the flashrom command under the "Flashing coreboot" section in go/cyan-care (also the dut-control commands, but the flashrom command is likely to be more interesting as flashrom could be in a bad state).

It'd be good to a flashrom read before trying that write command again and save the result.

the flashrom -V output should show at what commit it was built at: If it's after commit 5503150, you've likely been impacted by crbug.com/854833

If it is indeed after 5503150 the next troubleshooting step is to make a build before that commit or from a release branch and repeat the "Flashing coreboot" section.

go/cyan-care doesn't cover how to preserve VPD for cyan, so pause at this point and give the device to tgillella@ and the fw test team will investigate

Looking at the sample failure logs from crbug.com/854833, it seems like we encountered this issue. The device is handed over to tgillella@ for further investigations.

Cyan device with listed configurations handed over to +aashutoshk@chromium.org for wifi testing.

Type of hardware  : cyan PVT SKU1 Asset# C037007
Chrome OS Version : 10718.16.0 (Official Build) dev-channel cyan test
BIOS Version      : Google_Cyan.7287.57.100 / Google_Cyan.7287.57.180
EC Version        : cyan_v1.1.3571-7ae3bf3 / cyan_v1.1.3575-c3321a1

CPU arch     : x86_64
CPU model    : Intel(R) Celeron(R) CPU N3050 @ 1.60GHz
CPU speed    : 2249.1001
Total Memory : 1993592 kB
Memory Type  :
MMC Model    : HAG2e
MMC Firmware : 0x0300000000000000

VPD info:
  mlb_serial_number=5380J0QFMBQC0001C
  initial_locale=en-US
  initial_timezone=America/Los_Angeles
  keyboard_layout=xkb:us::eng
  region=us
  rlz_brand_code=ACAR
  serial_number=NXG55AA004542003B67600
  in_accel_x_base_calibbias=0
  in_accel_y_base_calibbias=-35
  in_accel_z_base_calibbias=17
  in_accel_x_lid_calibbias=-66
  in_accel_y_lid_calibbias=35
  in_accel_z_lid_calibbias=3

It looks like there is an open bug for the issue we encountered (comment#10). I have nothing to add here, and we can close this issue or firmware team can own it.