IPCC Memory manager channel (TL_MM_***)

[DS.4]

Would like to have a better understanding on the IPCC memory manager channel.

(Have read the AN5289 notes)

Appreciate If you can shed more light on it.

What is it purpose?

Why do we have to clear it after some events?

What are its memory parts purpose ?

a. BleSpareEvtBuffer

b. SystemSpareEvtBuffer

c. EvtPool

d. POOL_SIZE

In what situation it is used?

Thanks

[Remi QUINTIN · Accepted solution]

There are not too many details regarding IPCC management as there is nothing a user can customize, and we prefer to avoid too much support on this.

The lower interface that should be used is TL_***() which is described in the AN5289.

There are MSCs as well that describe the communication flow between the two CPUs.

Here are anyway some answers:

- How does CPU2 know where to put the answers for IPCC CPU1 requests?

> BLE and System channels are using the Command buffer to post the response.

- Regarding p_mem_manager_table->pevt_free_buffer_queue = (uint8_t*)&FreeBufQueue: What is this buffer used for?

- This buffer is filled every user event RX occupied event. Who empties it?

> This is not a buffer but a queue where buffer addresses are chained. Asynchronous event received from CPU2 need the associated buffer to be freed/released back to CPU2. All free buffers are pushed in that queue.

- Is CPU2 accessing this buffer?

> Yes, CPU2 is retrieving those free buffers to put them back in its event queue to be used later on.

- Does it have something to do with the SystemEvtQueue buffer?

> SystemEvtQueue is the other way. A system event is posted by the CPU2 in the SystemEvtQueue . Once the CPU1 has read the system event, it shall free it to the FreeBufQueue

There is the same thing for BLE : There is a received queue to receive Asynchronous BLE event and once done, they are free to FreeBufQueue

- What are these used for?

tl_mm_config.p_BleSpareEvtBuffer = BleSpareEvtBuffer;

tl_mm_config.p_SystemSpareEvtBuffer = SystemSpareEvtBuffer;

> These two buffers are currently not used. They should be kept available as some next CM0+ release may use them. When this happens, it will be transparent to the user and backward compatible.

- What are these used for?

tl_mm_config.p_AsynchEvtPool = EvtPool;

tl_mm_config.AsynchEvtPoolSize = POOL_SIZE;

The BLE and System channel asynchronous events are taken from that pool and sent to CPU1. When CPU1 pushes back a received asynchronous event to the FreeBufQueue,  CPU2 reads them from the FreeBufQueue to push them back to the EvtPool.

- How are read /write accesses performed in the IPCC? Where are the read/write/queue addresses?

> IPCC does not hold any buffer/queue. It is just a HW IP to support the implementation of a Mailbox. Its only purpose is to generate an event from a CPU to the other one and get an acknowledge when the event has been handled.

All communications are done through the queue and buffers as already described. When a buffer is filled and chained to a queue, the IPCC is triggered to signal the other CPU a message has been posted in the queue. The buffer addresses to be used by CPU2 are all given in the shared table. CPU1 shall fill the shared table with all information and on CPU2 boot, CPU2 will read that information.

- How is the memory management channel connected to other IPCC channels (send free command)?

> The memory channel is used only to free back buffers.

Roughly :

* Buffers used for asynchronous events ( BLE or System) are taken from EvtPool and filled by CPU2

* The filled buffer is then queued into the SystemEvtQueue (System) or the HciAsynchEventQueue (BLE)

* IPCC is triggered (either system or BLE channel) to notify CPU1 about a buffer posted in the receive queue

* CPU1 takes the buffer from the queue and reads it

* Once done, CPU1 posts the buffer back into the FreeBufQueue

* CPU1 triggers IPCC ( memory channel) to notify CPU2 a buffer has been released into the FreeBufQueue

* CPU2 retrieves the buffers from the FreeBufQueue and put it back to EvtPool.

This description is an overview, in details we have more chaining queues but the concept above is correct.