ESP32 Forum

Hi everyone,

I am working with the ESP32-P4 and using the PARLIO (Parallel IO) peripheral for transmission. I am trying to transmit multiple buffers consecutively, but I am running into an issue with the callback event data.

I have registered the following TX done callback:

C
static bool IRAM_ATTR parlio_tx_done_cb(parlio_tx_unit_handle_t tx_unit, const parlio_tx_done_event_data_t *edata, void *user_ctx)
{
// Inside this callback, edata appears to be 0 / empty

// Example: checking edata properties here yields 0x00
return false;
}
The Problem:
Whenever this callback is triggered, the edata parameter (or its contents) always evaluates to 0. I expected edata to contain information about the transaction that just finished (such as the buffer address or length).

Observations:
Interestingly, when I monitor the buffer switching (e.g., keeping track of the previous and present buffer addresses in a loop or through a buffer switch logic), the addresses are correct and the switch happens successfully. The hardware seems to be processing the buffers properly, but the event data passed to the parlio_tx_done_cb is completely empty/zero.

There is no members in parlio_tx_done_event_data_t, while parlio_tx_buffer_switched_event_data_t has teo members , is this something missed ?

Environment:

Target: ESP32-P4

ESP-IDF Version: 6.01

My Questions:

Is it expected behavior for edata to be 0x00 / empty during multiple or continuous buffer transmissions with PARLIO on the ESP32-P4?

Is there a specific configuration I need to enable to populate edata correctly?

Could this be an issue with the underlying DMA descriptor handling in the current ESP-IDF version for the P4?

Any guidance or workarounds would be greatly appreciated. Thank you!

Is it expected behavior for edata to be 0x00 / empty during multiple or continuous buffer transmissions with PARLIO on the ESP32-P4?

Is there a specific configuration I need to enable to populate edata correctly?

Given that parlio_tx_done_event_data_t is an empty struct, there cannot be any data in it.
When you're transmitting multiple buffers, what would you expect the struct to contain?

Sometimes (callback) functions are declared to take an argument even though it is not actually used, or an empty struct. This is done for consistency between callback function signatures, and to provide the possibility to add data/fields to the struct in the future without breaking existing code ("forward-compatibility").

Thank you for the clarification! It makes sense regarding forward-compatibility and API consistency. It is good to know it is by design and not a bug or pending in implementation (Hopefully).

To answer your question: I was expecting the struct to contain the memory address of the buffer that just finished transmitting (e.g., a void *finished_buffer_addr), just like on_buffer_switched callback() which is a sister functionality and does actually returns some data

Why I expected this:
When queuing up multiple buffers sequentially via DMA using parlio_tx_unit_transmit(), a logic design can send them asynchronously. When the tx_done callback eventually fires, the application needs to know which specific buffer just finished so that it can safely free or process further that memory, recycle it, or update a state machine. Since user_ctx is static per TX unit (set once during registration) rather than per-transaction, there is no built-in way in tx_done to identify the completed buffer without maintaining a mirrored software FIFO queue.

Thanks again for taking the time to explain the design intent behind the empty struct.

I was expecting the struct to contain the memory address of the buffer that just finished transmitting (e.g., a void *finished_buffer_addr), just like on_buffer_switched callback() which is a sister functionality and does actually returns some data

Checking the IDF docs, I agree that the tx_done callback should actually receive at least some transaction-specific argument, like the pointer to the buffer used, and not only the per-driver user_ctx. Might be worth creating a feature request issue.

Thanks for validating that! I completely agree—having it mirror the design of on_buffer_switched would make the API much more robust for asynchronous queueing and better handling when the buffer is used .
Parallel io is really a nice addition hope it evolves a bit more with multiple units of tx and rx