Skip to content

Fix processing of received ESP_HCI_IF (EHM-77) #74

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

OYTIS
Copy link

@OYTIS OYTIS commented Jul 14, 2025

Greetings!

We have found that in order for esp-hosted-mcu firmware to work as an HCI controller for our host, we need to get rid of decrementing the payload pointer. We are not using the host code from this repo, but are reasonably sure that our outgoing ESP_HCI_IF packets are well-formed, consisting of esp_payload_header followed by H4 HCI packet. The last esp-idf version we've been testing with is espressif/esp-idf@67e5e59

Decrementing the payload seems to break processing of incoming HCI packets
as long as they are well-formed H4 packets with esp_payload_header
prepended
@espressif-bot espressif-bot added the Status: Opened Issue is new label Jul 14, 2025
@github-actions github-actions bot changed the title Fix processing of received ESP_HCI_IF Fix processing of received ESP_HCI_IF (EHM-77) Jul 14, 2025
@mantriyogesh
Copy link
Collaborator

@SohKamYung-Espressif PTAL..

@SohKamYung-Espressif
Copy link
Collaborator

Hi @OYTIS

In our low level transport code for the host, for example here for SDIO

// copy first byte of payload into header

we move the HCI header into the Hosted payload header and copy the payload, less the header. On the slave, this HCI header is restored by moving the pointer back one byte so it points to the HCI header data in the Hosted payload header.

This was done to maintain compatibility with the slave BT code for the ESP-Hosted-FG implementation.

Can you check your host transport implementation whether it also moves the HCI header to the Hosted payload header?

@OYTIS
Copy link
Author

OYTIS commented Jul 16, 2025

@SohKamYung-Espressif Thank you! We had to change it for an earlier version too, but never made the change public.

So as I understand this can't be fixed, because it would break backwards compatibility, so instead host code should deviate from the protocol?

@SohKamYung-Espressif
Copy link
Collaborator

@OYTIS

So as I understand this can't be fixed, because it would break backwards compatibility, so instead host code should deviate from the protocol?

Yes, the change would break backward compatibility in ESP-Hosted-MCU.

@OYTIS
Copy link
Author

OYTIS commented Jul 16, 2025

@SohKamYung-Espressif Got it! How valuable is the backwards compatibility here? Say, protobuf protocol seems to be rewritten, so the host code would not be compatible with esp-hosted-fg.

If it's a good point to break it, we could fix it on the host side too.

@SohKamYung-Espressif
Copy link
Collaborator

How valuable is the backwards compatibility here?

We may also want to unify the underlying slave transport code between ESP-Hosted-FG and ESP-Hosted-MCU in the future, so we want to keep the underlying transport details the same.

The RPC Protobuf commands between FG and MCU differ, but this in the upper layer. The underlying transport still remains the same for both.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Opened Issue is new
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants