Direct Memory Access Interface
Table of content
The openMSP430 Direct-Memory-Access interface acts as a gateway to the whole logical 64kB memory space and can
be enabled be uncommenting the DMA_IF_EN macro in the "openMSP430_defines.sv"
// Include/Exclude DMA interface support
It supports the efficient connection of Bootloader, DMA controller, Memory-BIST or any other hardware
unit requiring direct read/write access to the CPU memory space.
The interface is also designed as to reuse the existing arbitration logic within the memory-backbone
and thus minimize to timing costs of its physical implementation (i.e. no additional muxing layer on
an already critical timing path).
An simple system using the DMA interface typically consists of a DMA master directly connected to
However, it is also possible to combine different DMA masters using a custom arbitration logic:
2. Signal list
||This clock times all DMA transfers. All signal timings are related to the rising edge of MCLK.
||The system reset is active HIGH and is used to reset the sytem, including the DMA master(s).
||When HIGH in a Low-Power-Mode, the wakeup signal restores the clocks necessary for the DMA transfer (see ASIC Implementation section).
||This is the 15-bit address bus allowing to access the 64kB address space (16b words).
Write data bus
||The write data bus is used to transfer data from the DMA master to openMSP430 system during write operations.
Read data bus
||The read data bus is used to transfer data from the openMSP430 system to the DMA master during read operations.
||Indicates that the current DMA transfer is active.
||When HIGH, this signal indicates a write transfer on the selected byte, and a read transfer when LOW.
||When HIGH, this signal indicates a high priority DMA transfer (i.e. CPU is stopped). When LOW, low priority DMA transfer have to wait for the CPU to free the accessed ressource.
||When HIGH the DMA_READY signal indicates that a transfer has finished on the bus. This signal may be driven LOW to add wait states to the transfer.
||The transfer response provides additional information on the status of a transfer (OKAY if LOW, ERROR when HIGH).
3.1 Simple transfer
The following figure shows the simplest transfer, one with no wait states.
In a simple transfer with no wait states:
- The DMA master drives the address, control signals and write data onto the bus after the rising edge of MCLK.
- The openMSP430 ressource (pmem/dmem/peripheral) then samples the address, control and write data information on the next rising edge of the clock.
- For read access, after the openMSP430 ressource has sampled the address and control it can start to drive the read data
and this is sampled by the DMA master on the third rising edge of the clock.
3.2 Transfer with wait states
The openMSP430 can insert wait states into any transfer, as shown in the following figure, which extends
the transfer by two clock cycles, thus taking additional time for completion.
For both read and write operations the DMA master must hold the address, control and write data stable throughout the extended cycles.
wait states are inserted by the openMSP430 if the CPU is currently busy reading or writing to the same ressource that the DMA controller also wants to access.
3.3 Multiple transfers
The following figure shows three transfers to unrelated addresses, A, B & C.
We can here observe:
- the transfers to addresses A and C are both zero wait state.
- the transfer to address B is one wait state.
- the read data from A is available during the first clock cycle when the address and control B are applied.
- the read data from B is available during the clock cycle when the address and control C are applied.
3.4 Transfer response
The following figure shows two transfers to unrelated addresses, A & B.
We can here observe:
- the transfer to address A returns an ERROR response (note that transfer returning an ERROR response never have wait states).
- the transfer to address B is a regular transfer (i.e. OKAY response) without wait state.
an ERROR response are generated if the transfer address lays between the program and data memories, where nothing is mapped.
3.5 Priority control
3.5.1 Data rate control
The DMA_PRIORITY control signal is available to the DMA master for controlling the application data rate requirements.
- When CLEARED, DMA transfers have a fixed lower priority than the CPU. This means that depending on the
exact kind of instructions currently executed by the CPU, the completion time of the DMA transfers cannot be
predicted (i.e. DMA transfers are completed only when the CPU is not accessing the trageted ressource).
- When SET, DMA transfers have a fixed higher priority over the CPU. This means that the CPU will
will stop execution and give the full bandwidth to the DMA controller. In that scenario, DMA transfers complete
in a single clock cycle (i.e. without any wait states), as the targeted ressources are always available
(i.e. the CPU is not executing).
- If the application requirements need something in between (namely a minimum DMA transfer data-rate with reduced effect
on the firmware exection), then the DMA master can dynamically change the DMA_PRIORITY as required.
These scenario are illustrated in the following figure.
We can here observe:
- phase A illustrates LOW-PRIORITY transfers. Less DMA transfer are completed during that time as shown by the number of wait states.
- phase B illustrates HIGH-PRIORITY transfers. DMA transfers are completed with each clock cycle (i.e. no wait state).
- phase C illustrates MIXED-PRIORITY transfers where the DMA controller is dynamically adjusting the priority to achieve its target minimum data-rate.
3.5.2 Bootloader case
In general, the purpose of a bootloader is to initialize the program memory at startup (i.e after Power-On-Reset).
DMA transfers driven by the bootloader should therefore be performed in HIGH-PRIORITY mode, as the CPU should not start
executing instructions on a non-initialized memory.
Once the memory initialization is completed, a reset pulse should be generated by the bootloader to make sure the CPU
re-fetches the new RESET vector from the program memory.
A bootloader could be for example be connected as following:
The bootloading sequence is illustrated in the following figure:
4. ASIC Implementation
4.1 Clock domains
If the ASIC low power options are enabled, it is possible to perform DMA accesses when the main CPU is in any
However, in order to avoid unnecessary power consumption while restoring the clocks for the DMA transfer, the MCLK
system clock has been split into two clock domains.
- MCLK_CPU : clocks the CPU core itself, namely the frontend and execution logic.
When the CPU is in LPMx mode, this clock is ALWAYS OFF, even if a DMA transfer is currently on going.
- MCLK_DMA : clocks the rest of the system (excluding the DBG interface) and gives access to the 64kB memory
adddress range to the DMA master. This clock is restored in LPMx modes by asserting the DMA_WKUP pin.
This table summarizes the clock operating modes:
Clock domains are illustrated in the following diagram:
4.2 DMA wakeup
As shown in the "Peripherals" chapter, the Basic-Clock-Module has several
control registers giving some flexibility to the firmware as to which clocks
are restored when the DMA_WKUP pin is asserted.
- DMA_SCG1 : Restore SMCLK with DMA wakeup
- DMA_SCG0 : Restore DCO oscillator with DMA wakeup
- DMA_OSCOFF : Restore LFXT oscillator with DMA wakeup
- DMA_CPUOFF : Restore MCLK_DMA with DMA wakeup
Note that the DMA_WKUP functionality can be disabled by keeping all these bitfields CLEARED