 Welcome to the presentation of the STM32WL5 Direct Memory Access Controller, or DMA. It covers the main features of the DMA controller module, enhanced by the new DMA Request Multiplexer, or DMAMux module. The main application benefit of the DMA is to offload the CPU for data transfers from any memory mapped source towards any memory mapped destination. STM32WL5 DMA features two DMA controllers. For each DMA controller, it is possible to do programmable block transfers with seven concurrent channels, each of which is independently configurable. Programmable channel-based priorities and data transfers via the AHB Masterport connected to the bus matrix. There is also a DMA Request Router, or DMAMux, with Programmable Request Source Selection, either from a peripheral in DMA mode or from a trigger and then internally generated. Synchronization mode, from a synchronization input or hardware event with a DMAMux Request Counter. And Request Chaining, with the DMAMux Request Counter to generate an event that is an input trigger or synchronization to another request or channel. There are 38 peripheral requests and four DMAMux Request Generators. There are 21 triggers and synchronization inputs. There are 14 DMA channels or requests. Let's focus on the STM32WB DMA controller. Each channel of the DMA controller is independently configurable. A channel can be assigned to a DMA hardware request from a peripheral in peripheral to memory or memory to peripheral data transfers. Alternatively, a channel is assigned to a software request in memory to memory data transfers. A channel is programmed with a priority level and a channel is programmed for a number of data transfers at a block level. The software can control a channel via the separated interrupts and or flags upon Programmable Events such as a block transfer complete and or a half block transfer complete and or a transfer error. A faulty channel is automatically disabled in case of a bus access error. A channel is programmed for a number of data transfers at a block level with independent source and destination data size. Independent source and destination start address. Independent source and destination address increment, either contiguously incremented or at a fixed address. Programmable amount of data to be transferred within a block. Up to 65,535 source data automatically decremented by hardware. In circular buffer mode, continuous data transfer from or to a peripheral when a block transfer is completed. The programmed amount of data to be transferred within a block is automatically reloaded by hardware as well as the source and destination start addresses. In memory to memory mode, a block transfer starts as soon as the channel is enabled. There is no hardware request. Whereas in peripheral to memory and memory to peripheral modes, a block transfer starts as soon as both the channel is enabled and the peripheral sends a DMA hardware request. A DMA hardware request identifies a single DMA data transfer. Each DMA hardware request is paced and granted by the DMA when each data is successfully transferred to the destination. In any mode, channels arbitration is reassessed between every data transfer. Each DMA channel can notify software with an interrupt triggered by any of four possible events. Half block transfer completion, block transfer completion, transfer error, any of the three above events, in other words global. The DMA MUX has two main sub blocks, the request multiplexer and the request generator. The DMA MUX request multiplexer enables routing a DMA request from the peripherals to the DMA controllers. The routing function is insured by the programmable multi-channel DMA request multiplexer. Each channel selects a unique DMA request unconditionally or synchronously with events from its DMA MUX synchronization inputs. The DMA MUX may also be used as a DMA request generator from programmable events on its input trigger signals. A DMA request multiplexer channel generates both a request to the DMA controller and an event that can be used as a synchronization input as well as a trigger input. Do not confuse DMA request generator channels 0-3 with DMA request multiplexer channels 0-13. For each multiplexer channel there is a configuration register. DMA MUX CXCR with programmable input request selection via DMA REQ ID field. For each request from a peripheral working in DMA mode, a DMA REQ ID is assigned. DMA REQ ID equals 0X00 corresponds to no DMA request selected. After having configured this channel and the DMA controller channel to which it is routed, the DMA channel can be enabled. It is not allowed to configure two different channels with the same DMA request input. For each multiplexer channel, a built-in DMA request counter is programmable via the NBREQ field. A served DMA request decrements the programmed DMA request counter. At its underrun, the DMA request counter is automatically reloaded with the programmed value in the NBREQ field. At its underrun, a DMA MUX event can be generated if enabled via EGE field. Two DMA MUX events from channel 0 and 1 are looped back and connected to the DMA MUX as trigger inputs and synchronization inputs. This allows request chaining for another different DMA channel via synchronization and or trigger. For each multiplexer channel there are two operating modes as programmed via the DMA MUX SE field. Unconditional mode. Input request is output as is. Synchronized mode. A number of requests is grouped and delayed or synchronized. For each multiplexer channel, security is enabled at the same time as the associated DMA channel as programmed via the DMA SECM field. When the request multiplexer channel is configured unconditionally, SE equals 0, the DMA request is transmitted as is and as paced by the DMA controller. When the DMA controller is served a day to transfer, the DMA request is de-asserted and the built-in DMA request counter is decremented. At the counter underrun, if enabled via the EGE field, an event can be generated. In synchronous mode additionally, the request is conditioned with a programmable synchronization input selection via sync ID field. A programmable synchronization event, none, rising, falling or either edge via SPOL field. Or the single built-in request counter via NBREQ field that may be also used for event generation. After the synchronization event, output DMA request is connected to the pending input request. At the counter underrun, DMA output request is disconnected from the multiplexer channel input. Finally, a synchronization overrun flag or SOFX in DMA Mux CSR is reported if a new synchronization event occurs before the counter underrun or an interrupt is then generated if enabled via SOIE field. When the DMA Mux channel is configured in synchronous mode, its behavior is as follows. The request multiplexer input or DMA request from the peripheral can be pending and it will not be forwarded on the DMA Mux request multiplexer output until the synchronization event is received. Then the request multiplexer connects its input and output and all the peripheral requests will be forwarded. Each forwarded and granted DMA request decrements the requested multiplexer counter set at a defined programmed value. When the counter reaches zero, the connection between the DMA controller and the peripheral is cut, waiting for a new synchronization event. For each underrun of the counter, a request multiplexer can generate an optional event to synchronize and or trigger a second DMA Mux request multiplexer channel. The same event can be used in some low power scenarios to switch the system back to stop mode without CPU intervention. Synchronization mode can be used to automatically synchronize data transfers with a timer, for example, or to condition transfers from any peripheral event that is mapped as a synchronization input. Additionally, a synchronization overflow can notify the software if a programmed number of DMA requests has not been completed between two synchronization events. For each request generator channel, a DMA request can be generated following a trigger event and selected as input of a DMA request multiplexer channel via the DMA-REQID field of the DMA Mux CXCR. The request is generated via the configuration register DMA Mux RGXCR, if enabled by GE field with Programmable Trigger Input Selection via SIG ID field, Programmable Trigger Event, None, Rising, Falling, or Either Edge via GPOL field, or a built-in request counter via GNB-REQ field. A served DMA request decrements the programmed request counter. At its underrun, request counter is automatically reloaded with the programmed value in the GNB-REQ field, and the request generator stops generating a request. A trigger overrun flag or OFX in DMA Mux RGXCR is reported if a new trigger event occurs before the counter underrun, or an interrupt is then generated if enabled via OIE field. On a trigger event, a program number of DMA requests GNB-REQ plus one is generated. There may be a trigger overflow if two trigger events occur before GNB-REQ plus one requests and data transfers are completed. The table shows the STM32WL5 mapping of the DMA Mux request multiplexer inputs for any channel. A signing request input is programmed by the DMA-REQ ID for any DMA Mux request multiplexer channel, or DMA Mux CXCR register. The same request input must not be mapped to two different channels. This table shows the STM32WL5 mapping of the trigger inputs and the synchronization inputs for any channel. A signing a trigger input is programmed by the CIG ID field of any DMA Mux request generator, or DMA Mux RGXCR register. A signing a synchronization input is programmed by the CIG ID field of any DMA Mux request multiplexer channel, or DMA Mux CXCR register. Each DMA Mux request generator channel can notify software of a trigger overrun. Each DMA request multiplexer channel can notify software of a synchronization overrun. This table indicates the state of the DMA controller and DMA Mux according to the power mode. In sleep and low power sleep modes, the DMA controller and the DMA Mux remain active and can be used, for example, to transfer UART or I2C received characters to memory, and afterwards to wake up the CPU.