Broken HDMI CEC with N2+ on Sony TV (includes logic analyser traces!)

[micolous]

I’ve recently migrated from Minix Neo U9-H running CoreElec 9.2.8 to an Odroid N2+ running CoreElec 19.3. The setup is normally connected to a Sony Android TV.

Everything works except HDMI-CEC (which worked on the Minix Neo U9-H) – the N2+ doesn’t appear with a “CoreElec” label in the input selector, and none of the TV remote controls work.

The N2+ works fine with CEC on my Panasonic TV.

I suspect there’s an issue with CE’s version of the aocec module.

My normal setup is as follows:

Sony TV (HDMI 2) -> ODroid N2+ (CoreElec device)
Sony TV (HDMI 4) -> Yamaha AVR -> various devices

For testing, I disconnected all other devices, so that the only thing connected to the TV is the ODroid N2+. I’ve tried multiple cables, running with completely fresh OpenElec installs (with no configuration changed from default).

Using echo 1 > /sys/class/aocec/dbg_en, shutting down Kodi, and running cec-client, it looks like:

• CE is receiving messages from my TV correctly, I get messages in dmesg like:

  [ 4935.992679@0] cectx ff80023c.aocec: cec b rx len 2: 01 83
  [ 4935.992729@0] cectx ff80023c.aocec: read msg len=2
  

• CE is trying to respond to these messages, but cec-client gets a bunch of write failures:

  TRAFFIC: [            8877]	>> 01
  TRAFFIC: [           10645]	>> 01:83
  TRAFFIC: [           10645]	<< 1f:84:20:00:01
  WARNING: [           10659]	Write: write failed
  TRAFFIC: [           10659]	<< 1f:84:20:00:01
  WARNING: [           10675]	Write: write failed
  

  dmesg also reports the attempts to send messages:

  [ 4935.992968@1] cectx ff80023c.aocec: cecb: tx len: 5 data: 1f 84 20 00 01
  [ 4936.007399@1] cectx ff80023c.aocec: cecb: tx len: 5 data: 1f 84 20 00 01
  

I’ve attached a logic analyser between the HDMI CEC pin and GND:

That looks to me like CE is able to pull the line low to ACK, but when sending its own messages, it pulls the line low for 3.7ms (correct), but then doesn’t pull it low again to start transmission… it just pulls it low again after 12.2ms to send another start bit. This doesn’t seems incorrect per CEC 5.2.1, which says a device needs to start transmission of bits at T+4.3-4.7ms.

When I disconnect the TV and run poll 0, this looks fine (though there is no ACK from the TV, because that’s disconnected).

I see the same behaviour on the N2+ with CoreElec 9.2.8 and 19.4 nightly (2021-11-06).

Both the ODroid N2+ and Minix U9-H work fine with another Panasonic TV I have.

(I have more logic analyser traces, but I’m not allowed to post more than one image as a new user.)

# dmesg | grep cec
[    0.949695@3] cectx ff80023c.aocec: cec driver date:2020/03/16:reduece no msg in sleep time
[    0.949885@4] cectx ff80023c.aocec: compatible:amlogic, aocec-g12a
[    0.949887@4] cectx ff80023c.aocec: cecb_ver:0x1
[    0.949889@4] cectx ff80023c.aocec: line_reg:0x1
[    0.949889@4] cectx ff80023c.aocec: line_bit:0x3
[    0.949890@4] cectx ff80023c.aocec: ee_to_ao:0x1
[    0.949987@4] input: cec_input as /devices/virtual/input/input0
[    0.950068@3] cectx ff80023c.aocec: not find 'port_num'
[    0.950070@3] cectx ff80023c.aocec: using cec:1
[    0.950096@3] cectx ff80023c.aocec: no hdmirx regs
[    0.950098@3] cectx ff80023c.aocec: no hhi regs
[    0.950103@3] cectx ff80023c.aocec: not find 'arc_port_mask'
[    0.950105@3] cectx ff80023c.aocec: not find 'output'
[    0.951621@3] cectx ff80023c.aocec: wakeup_reason:0x0
[    0.951675@3] cectx ff80023c.aocec: cev val1: 0x0;val2: 0x0
[    0.951676@3] cectx ff80023c.aocec: aml_cec_probe success end

[micolous]

Here’s a trace from the Odroid N2+ with no TV attached, running poll 0:

There’s no ACK because there’s no TV attached, but otherwise looks OK.

My suspicion is that aocec is halting CEC transmission with the Sony TV, because it thinks something else is holding the line down.

All the logic analyser traces were taken using the same HDMI cable.

[micolous]

I’ve tried connecting the N2+ to the Yamaha AVR without the TV. CEC works there – I’m able to run scan in cec-client and get back devices, and I can see CEC packets from the N2+ with the logic analyser.

Doing the same with the TV plugged in, the N2+ sends the start bit, and then the first bit, then messes up the timing of the second bit, and then tries sending another start bit and gives up:

TRAFFIC: [          277096]	>> 01
TRAFFIC: [          278760]	>> 01:83
TRAFFIC: [          278760]	<< 1f:84:41:00:01
WARNING: [          278774]	Write: write failed
TRAFFIC: [          278774]	<< 1f:84:41:00:01
WARNING: [          278790]	Write: write failed

I’m out of ideas 🤷

[Portisch]

Nice debug, I don’t have much time right now but I think your problem is about the Amlogic CEC hardware implementation. The SoC include CEC hardware like a external peripheral with TX/RX.
And the problem is there is no real hardware register description available.
You can try to search for S922X or S905X3 (limited) datasheets as Hardkernel and/or Khadas have them online.

Other devices like AVR and I think also RPis do use software CEC pin control, so you have easy access to the CEC bus and adjust timings to your need.

There are some commits about arbitration like this:

cec: cec b ARB timing cause cec 9.6.1 fail [1/1]

Maybe you keep digging in this driver and take a look into the history.

[micolous]

Ah ok, I was worried the hardware might limit access like that. I’ll have to have a look into that.

I managed to get it working now, and I’m kicking myself for being such a fool, because there was one thing I didn’t unplug at the TV side: a long (~20m) HDMI cable, with nothing plugged into the other end. Because it was unplugged at the other end, I didn’t think anything of it.

I was chatting with a friend about the issue yesterday, and they suggested some capacitance or inductance in a cable (“but it works with the same cables!”)… but then it clicked this morning that all the CEC lines are tied together for every device in the chain – so any cable can trigger that problem…

So:

• When it’s not working, unplugging the long cable, and switching HDMI input away and back to the N2+ again, everything works again.
• Rebooting the N2+ when the long cable is unplugged, everything comes up correctly.
• Plugging the long cable in again after N2+ was working, CEC (remote) controls still work, but it looks like the N2+ stops being able to send its own commands like before.

If the N2+ starts up with that long cable attached, CEC won’t work on the N2+ because it can never finish the initial handshake process.

I’m pretty sure this means the problem is entirely in the analogue domain, which gets it stuck behind Amlogic’s CEC implementation. Every other device I’ve got hooked up that supports CEC is fine with the long cable: the Minix box (Amlogic S912), the AVR, and a Chromecast Ultra.

That makes me feel like it’s an Amlogic CEC bug, but I’d want to understand how much that long cable changes things. I’m not sure how to start measuring that.

[Portisch]

This is what a technician call “digital get analog again”. If you zoom in in to the digital signal and analyse the edges. These may the reason the hardware don’t understand it anymore if the rise and fall time is to much off from standard.