HDMI CEC - ESP32C6 - Not Receiving

[ryanww]

Hello,

I'm having an issue with the latest build running on an Seeed Studio XIAO ESP32C6 board. I can transmit CEC messages just fine, and the TV is turning on/off as it should be, but I never get any response. It's almost as though the pin isn't switching back to receive mode. Not sure if I'm doing anything wrong, but since I can send messages out, i'm assuming not.

I'm not sure what else to put here, so here is the log from messing with it.

00:00:00.250 CMD: Fall back to serial port, no SOF packet detected on USB port
00:00:00.251 HDW: ESP32-C6FH4 v0.1
00:00:00.268 UFS: FlashFS mounted with 304 kB free
00:00:00.282 CFG: Loaded from File, Count 44
00:00:00.288 QPC: Count 1
00:00:00.289 CFG: CR 396/699, Busy 0
00:00:00.290 SPI: Bus1 using GPIO19(CLK), GPIO18(MOSI) and GPIO20(MISO)
00:00:00.291 I2C: Bus1 using GPIO05(SCL) and GPIO04(SDA)
00:00:00.301 SCR: ufilesystem found
00:00:00.309 BRY: GC from 3828 to 3628 bytes, objects freed 4/17 (in 0 ms) - slots from 35/61 to 27/61
00:00:00.325 CFG: No '*.autoconf' file found
00:00:00.327 BRY: GC from 4956 to 3636 bytes, objects freed 8/27 (in 0 ms) - slots from 48/76 to 30/76
00:00:00.338 BRY: Berry initialized, RAM used 3636 bytes
00:00:00.344 BRY: No 'preinit.be'
00:00:00.344 SRC: Restart
00:00:00.345 Project tasmota - Tasmota Version 14.1.0(TasmoCompiler-esp32c6)-3_0_0(2024-07-31T02:28:55)
00:00:00.356 CEC: trying to read physical address
00:00:00.376 BRY: No 'autoexec.be'
00:00:00.416 CEC: Packet sent: 55 ACK
00:00:00.417 CEC: HDMI CEC initialized on GPIO 2, Logical address 15, Physical address 0x1000
00:00:00.568 CEC: Packet sent: FF84100005 ACK
00:00:00.571 WIF: Checking connection...
00:00:00.571 WIF: Attempting connection...
00:00:01.001 WIF: Connecting to AP1 rw Channel 11 BSSId 38:FF:36:13:C1:48 in mode HT20 as tasmota-219B44-7713...
00:00:01.031 WIF: IPv4 10.0.1.137, mask 255.255.255.0, gateway 10.0.1.1
00:00:03.462 WIF: Checking connection...
00:00:03.462 WIF: Connected
00:00:03.482 WIF: IPv6 Local fe80::5632:4ff:fe21:9b44%st1
00:00:03.715 HTP: Web server active on tasmota-219B44-7713 with IP address 10.0.1.137
00:00:03.717 NTP: Sync time...
00:00:03.723 WIF: DNS resolved '2.pool.ntp.org' (152.70.159.102) in 6 ms
00:00:03.754 RTC: UTC 2024-07-31T02:33:39Z, DST 2024-03-31T02:00:00, STD 2024-10-27T03:00:00
03:33:39.000 RTC: Synced by NTP
03:33:39.718 RSL: INFO1 = {"Info1":{"Module":"Seeed Studio XIAO ESP32C6","Version":"14.1.0(TasmoCompiler-esp32c6)","FallbackTopic":"cmnd/DVES_219B44_fb/","GroupTopic":"cmnd/tasmotas/"}}
03:33:39.730 RSL: INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"tasmota-219B44-7713","IPAddress":"10.0.1.137","IP6Global":"","IP6Local":"fe80::5632:4ff:fe21:9b44%st1"}}
03:33:39.741 RSL: INFO3 = {"Info3":{"RestartReason":"Software reset CPU","BootCount":26}}
03:33:39.754 TFS: File 'autoexec.bat' not found
03:33:42.482 WIF: IPv6 Global fd69:ee9a:f6c3:8042:5632:4ff:fe21:9b44
03:33:42.726 QPC: Reset
03:33:43.728 BRY: GC from 4688 to 3868 bytes, objects freed 15/33 (in 0 ms) - slots from 61/76 to 39/76
03:33:43.731 RSL: STATE = {"Time":"2024-07-31T03:33:43","Uptime":"0T00:00:08","UptimeSec":8,"Heap":309,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"Berry":{"HeapUsed":3,"Objects":33},"Wifi":{"AP":1,"SSId":"rw","BSSId":"38:FF:36:13:C1:48","Channel":11,"Mode":"HT20","RSSI":74,"Signal":-63,"LinkCount":1,"Downtime":"0T00:00:03"}}
03:33:44.679 APP: Boot Count 26
03:33:44.730 HTP: Main Menu
03:33:45.458 CFG: Saved, Count 45, Bytes 4096
03:33:46.446 HTP: Tools
04:07:18.478 WIF: Checking connection...
04:07:22.590 CMD: HdmiSend 8F
04:07:22.591 SRC: WebConsole from 10.0.1.110
04:07:22.592 CMD: Grp 0, Cmd 'HDMISEND', Idx 1, Len 2, Pld 8, Data '8F'
04:07:22.595 RSL: RESULT = {"HdmiSend":"Done"}
04:07:22.639 CEC: Packet sent: F08F NAK
04:07:29.365 CMD: HdmiSend 8F
04:07:29.366 SRC: WebConsole from 10.0.1.110
04:07:29.368 CMD: Grp 0, Cmd 'HDMISEND', Idx 1, Len 2, Pld 8, Data '8F'
04:07:29.370 RSL: RESULT = {"HdmiSend":"Done"}
04:07:29.439 CEC: Packet sent: F08F ACK

[s-hadinger]

I see one problem in your setup. Tasmota tries to get logical address 5 (AUDIO_SYSTEM) but it is already used by another device; then revert to the default F logical address, which can cause problems.

Try HDMIType 4 instead, which is a more classical device type to use.

[ryanww]

Thanks for the suggestion. I gave that a try, but that still doesnt work. I also tried device type 3 as well, and no luck either. Pasted the below with type 4.

00:00:00.250 CMD: Fall back to serial port, no SOF packet detected on USB port
00:00:00.251 HDW: ESP32-C6FH4 v0.1 
00:00:00.264 UFS: FlashFS mounted with 304 kB free
00:00:00.276 CFG: Loaded from File, Count 48
00:00:00.282 QPC: Count 1
00:00:00.283 CFG: CR 396/699, Busy 0
00:00:00.284 SPI: Bus1 using GPIO19(CLK), GPIO18(MOSI) and GPIO20(MISO)
00:00:00.285 I2C: Bus1 using GPIO05(SCL) and GPIO04(SDA)
00:00:00.295 SCR: ufilesystem found
00:00:00.302 BRY: GC from 3828 to 3628 bytes, objects freed 4/17 (in 0 ms) - slots from 35/61 to 27/61
00:00:00.316 CFG: No '*.autoconf' file found
00:00:00.317 BRY: GC from 4956 to 3636 bytes, objects freed 8/27 (in 0 ms) - slots from 48/76 to 30/76
00:00:00.328 BRY: Berry initialized, RAM used 3636 bytes
00:00:00.333 BRY: No 'preinit.be'
00:00:00.333 SRC: Restart
00:00:00.334 Project tasmota - Tasmota Version 14.1.0(TasmoCompiler-esp32c6)-3_0_0(2024-07-31T02:28:55)
00:00:00.345 CEC: trying to read physical address
00:00:00.361 BRY: No 'autoexec.be'
00:00:00.400 CEC: Packet sent: 44 ACK
00:00:00.445 CEC: Packet sent: 88 NAK
00:00:00.445 CEC: HDMI CEC initialized on GPIO 2, Logical address 8, Physical address 0x1000
00:00:00.597 CEC: Packet sent: 8F84100004 ACK
00:00:00.600 WIF: Checking connection...
00:00:00.600 WIF: Attempting connection...
00:00:01.001 WIF: Connecting to AP1 rw Channel 11 BSSId 38:FF:36:13:C1:48 in mode HT20 as tasmota-219B44-7713...
00:00:01.056 WIF: IPv4 10.0.1.137, mask 255.255.255.0, gateway 10.0.1.1
00:00:03.380 WIF: Checking connection...
00:00:03.380 WIF: Connected
00:00:03.517 WIF: IPv6 Local fe80::5632:4ff:fe21:9b44%st1
00:00:03.634 HTP: Web server active on tasmota-219B44-7713 with IP address 10.0.1.137
00:00:03.681 NTP: Sync time...
00:00:03.699 WIF: DNS resolved '2.pool.ntp.org' (51.81.226.229) in 18 ms
00:00:03.740 RTC: UTC 2024-07-31T07:55:53Z, DST 2024-03-31T02:00:00, STD 2024-10-27T03:00:00
08:55:53.000 RTC: Synced by NTP
08:55:54.650 RSL: INFO1 = {"Info1":{"Module":"Seeed Studio XIAO ESP32C6","Version":"14.1.0(TasmoCompiler-esp32c6)","FallbackTopic":"cmnd/DVES_219B44_fb/","GroupTopic":"cmnd/tasmotas/"}}
08:55:54.661 RSL: INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"tasmota-219B44-7713","IPAddress":"10.0.1.137","IP6Global":"","IP6Local":"fe80::5632:4ff:fe21:9b44%st1"}}
08:55:54.672 RSL: INFO3 = {"Info3":{"RestartReason":"Software reset CPU","BootCount":27}}
08:55:54.685 TFS: File 'autoexec.bat' not found
08:55:57.517 WIF: IPv6 Global fd69:ee9a:f6c3:8042:5632:4ff:fe21:9b44
08:55:57.707 QPC: Reset
08:55:58.607 HTP: Main Menu
08:55:58.688 BRY: GC from 4688 to 3868 bytes, objects freed 15/33 (in 0 ms) - slots from 61/76 to 39/76
08:55:58.689 RSL: STATE = {"Time":"2024-07-31T08:55:58","Uptime":"0T00:00:09","UptimeSec":9,"Heap":303,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":26,"MqttCount":0,"Berry":{"HeapUsed":3,"Objects":33},"Wifi":{"AP":1,"SSId":"rw","BSSId":"38:FF:36:13:C1:48","Channel":11,"Mode":"HT20","RSSI":74,"Signal":-63,"LinkCount":1,"Downtime":"0T00:00:03"}}
08:55:59.686 APP: Boot Count 27
08:56:00.257 CFG: Saved, Count 49, Bytes 4096
08:56:01.096 HTP: Configuration
08:56:03.835 HTP: Main Menu
08:56:06.293 HTP: Tools
08:56:07.502 HTP: Console
08:56:13.422 WIF: Checking connection...
08:56:32.722 CMD: HdmiSend 04
08:56:32.723 SRC: WebConsole from 10.0.1.110
08:56:32.724 CMD: Grp 0, Cmd 'HDMISEND', Idx 1, Len 2, Pld 4, Data '04'
08:56:32.736 RSL: RESULT = {"HdmiSend":"Done"}
08:56:33.381 WIF: Checking connection...
08:56:47.470 CMD: HdmiSend 04
08:56:47.471 SRC: WebConsole from 10.0.1.110
08:56:47.472 CMD: Grp 0, Cmd 'HDMISEND', Idx 1, Len 2, Pld 4, Data '04'
08:56:47.484 RSL: RESULT = {"HdmiSend":"Done"}
08:56:53.385 WIF: Checking connection...
08:56:56.643 CMD: HdmiSend 36
08:56:56.644 SRC: WebConsole from 10.0.1.110
08:56:56.645 CMD: Grp 0, Cmd 'HDMISEND', Idx 1, Len 2, Pld 36, Data '36'
08:56:56.657 RSL: RESULT = {"HdmiSend":"Done"}
08:56:56.701 CEC: Packet sent: 8036 NAK
08:57:02.173 CMD: HdmiSend 04
08:57:02.173 SRC: WebConsole from 10.0.1.110
08:57:02.174 CMD: Grp 0, Cmd 'HDMISEND', Idx 1, Len 2, Pld 4, Data '04'
08:57:02.186 RSL: RESULT = {"HdmiSend":"Done"}
08:57:02.256 CEC: Packet sent: 8004 ACK
08:57:13.388 WIF: Checking connection...
08:57:15.196 CMD: HdmiSend 8F
08:57:15.197 SRC: WebConsole from 10.0.1.110
08:57:15.198 CMD: Grp 0, Cmd 'HDMISEND', Idx 1, Len 2, Pld 8, Data '8F'
08:57:15.210 RSL: RESULT = {"HdmiSend":"Done"}
08:57:15.278 CEC: Packet sent: 808F ACK
08:57:19.693 CMD: HdmiSend 8F
08:57:19.694 SRC: WebConsole from 10.0.1.110
08:57:19.695 CMD: Grp 0, Cmd 'HDMISEND', Idx 1, Len 2, Pld 8, Data '8F'
08:57:19.707 RSL: RESULT = {"HdmiSend":"Done"}
08:57:19.775 CEC: Packet sent: 808F ACK
08:57:28.300 CMD: HdmiSend 8F
08:57:28.301 SRC: WebConsole from 10.0.1.110
08:57:28.302 CMD: Grp 0, Cmd 'HDMISEND', Idx 1, Len 2, Pld 8, Data '8F'
08:57:28.314 RSL: RESULT = {"HdmiSend":"Done"}
08:57:28.382 CEC: Packet sent: 808F ACK

[ryanww]

I also tried rebooting both times, and confirmed on/off worked on all of these device numbers.

[s-hadinger]

Your logs look fine. Device number 4 seems already taken as well, it reverted to 8.

If the commands work, it just means that your TV does not respond to command 8F. You can try other commands.

It also looks like you didn't wire the I2C pins to read the EDID. It is not mandatory but preferred.

[ryanww]

Ah got it. I tried setting it to a few other things, and I'm seeing that it will either take it or not. That was another question I had -- I do have the SCA/SCL lines wired as it showed in the help article. I cross checked it with the board's pinout that support those associated ports, and I've checked the mapping within Tasmota. Still no go on that. I'm wondering if I may have soldered them backwards. I'll look at that when i'm physically at the board and see if swapping them resolves the initial poll not working for the edid. Thanks for the assistance!

[ryanww]

I tried reversing the two data lines, no luck. Must be something with this board version that this library can't figure out. I'm going to pull one of my Crestron buts from my inventory and that will give me raw send/receive control to see if this display works right.

[s-hadinger]

I would love to have a Wemos D1 Mini hat with double HDMI plugs. If anyone is skilled enough to create the PCB

[sfromis]

If you're ok with a bit of soldering, you could use a D1 Mini prototype perfboard PCB (same size as the D1 Mini), adding header rows in the middle connecting to the relevant gpios, along with a small board like this:

Random Aliexpress listing: https://www.aliexpress.com/item/1005004891830600.html

At least, that's what I'd do.

[barbudor]

[sfromis]

BTW... You can even get the double-headed HDMI breakout board including pins....
https://www.aliexpress.com/item/1005003632560554.html

(One nice thing about the Wemos D1 Mini form factor is that you can also get ESP32-S3, ESP32-S2 and ESP32-C3 boards with compatible pinout).

[s-hadinger]

Nice, I will try. Those Dupont cables are not reliable

[anishsane]

I am able to see the same observation on esp32 (devkit), esp32c6 (waveshare esp32c6 zero) and esp32c3 (some generic esp32c3 board).

I am able to send the HDMI commands and the devices respond correctly.
However, I am not seeing onHdmiReceived logs. Even the auto-respond messages are not triggering. (e.g. hardcoded power status, cec version etc replies)

[anishsane]

I can confirm that the ISR CEC_Run is not getting triggered.

I re-configured the same pin as Counter1, and the CounterIsrArg ISR got triggered when I sent cec message from R-Pi. So, the hardware connections should be right. I added Led toggle code in that ISR, for visual indication.

However, with nearly similar code, the CEC_Run ISR does not get triggered when the same pin was configured as HDMI_CEC.
I added an AddLog before attachInterruptArg to ensure that the CEC_Device::enableISR is getting called and it is reaching the attachInterruptArg call. I am not sure why it does not trigger the ISR on the GPIO CHANGE operation.

[anishsane]

The ISR not getting triggered is likely due to the HDMI_CEC pin switching between INPUT_PULLUP and OUTPUT.

I was able to replicate this behavior for Counter1 by changing it to OUTPUT, delay 250us, INPUT_PULLUP.
I did this in the CmndCounterType function, so that I could control the behavior via web console. After this function got called, the counter stopped updating. Also, the LED toggle logic stopped working, indicating that the ISR is not getting called anymore.

However, I was not able to fix it so far.
I could get ONE HdmiReceived message correctly by calling detachInterrupt from setLineState(state=0) and attachInterruptArg from setLineState(state=1, check=0)
However, it was not reliable.

Signing off for now.

[anishsane]

I was able to get HdmiReceived working with good consistency by physically shorting the GPIO13 (my esp32's hdmi_cec pin) with GPIO12.
Then use GPIO12 for interrupt.

Basically, I shorted 2 adjacent pins and used one for TX/setLineState (GPIO13) and one for RX/attachInterruptArg (GPIO12).

Maybe for ESP32, we could use 2 pins for HDMI_CEC (call the other as HDMI_CEC_rx?).

 _gpio = Pin(GPIO_HDMI_CEC); // GPIO13 in my case
 _gpio_rx = Pin(GPIO_HDMI_CEC_rx); // GPIO12 in my case.
 if (_gpio_rx < 0) _gpio_rx = _gpio; // Fall back to the single GPIO method as we do currently.

And attach an interrupt to _gpio_rx instead of _gpio.

It looks ugly and wastes a GPIO, but if we cannot find a software workaround, we may need to use this for ESP32.

[anishsane]

I made a change here: anishsane@9003520
It probably needs a cleanup in the enum list. I should probably add the new enum at the end to support upgrades from older version.

But I have verified this change to be working otherwise.

[s-hadinger]

This is good debugging, thanks. However I don't get why we need 2 Gpios for this. What prevents using the same GPIO for in/out and interrupt handling.

All in all, since we're doing bit banging, it's more reliable on ESP8266.