DMA Testing Guide

You can use the same set of source code to build the following +DMA test harnesses:

DMA test source files

The following test code are +available to test a DMA port.

+ + + + +File +Description +Location +Usage + + + + +t_dma.exe +User-side test harness to test the DMA framework +/e32test/dma/t_dma.cpp +Mandatory + + +d_dma.ldd +Simulation PSL to test the DMA framework +/e32test/dma/d_dma.cpp +Mandatory + + +dmasim.dll +Software simulation of DMA controller and the SHAI implemetation +e32test/dma/dmasim.cpp +Optional, only used to test software simulated DMA controller. + + +t_dmasim.exe +User-side test harness to test the simulated DMA controller +/e32test/dma/t_dma.cpp +Optional, only used to test software simulated DMA controller. + + +d_dmasim.ldd +Kernel-side test harness to test the simulated DMA controller +/e32test/dma/d_dma.cpp +Optional, only used to test software simulated DMA controller. + + + +

T_DMA.EXE is a user-side harness, +and is an automatic test included in the E32TEST suite. +It assumes that the underlying DMA controller supports memory to memory +transfers. This executable delegates most of the work to D_DMA.LDD , a logical device driver that acts as a client +for the DMA Framework. D_DMA.LDD links statically +against DMA.DLL, the DMA Framework kernel extension +must be built from the variant.

T_DMA.EXE delegates most of the work to D_DMA.LDD, which +is a logical device driver that acts as a client for the DMA Framework. +D_DMA.LDD links statically against DMA.DLL, the DMA Framework kernel +extension must be built from the variant. In practice, this means +that D_DMA.LDD must be specified in the test bld.inf for the variant being ported. For an example of this, see ...\template_variant\test\bld.inf.

D_DMA.LDD calls the DmaTestInfo() function in the PSL to +obtain the information on which channels are available to be used +by T_DMA to allow it to run multiple DMA channels simultaneously. +This is the template implementation:

struct TDmaTestInfo + { + /** Maximum transfer size in bytes for all channels (ie. the minimum of all channels' maximum size)*/ + TInt iMaxTransferSize; + /** 3->Memory buffers must be 4-byte aligned, 7->8-byte aligned, ... */ + TUint iMemAlignMask; + /** Cookie to pass to DDmaRequest::Fragment for memory-memory transfer*/ + TUint32 iMemMemPslInfo; + /** Number of test single-buffer channels */ + TInt iMaxSbChannels; + /** Pointer to array containing single-buffer test channel ids */ + TUint32* iSbChannels; + /** Number of test double-buffer channels */ + TInt iMaxDbChannels; + /** Pointer to array containing double-buffer test channel ids */ + TUint32* iDbChannels; + /** Number of test scatter-gather channels */ + TInt iMaxSgChannels; + /** Pointer to array containing scatter-gather test channel ids */ + TUint32* iSgChannels; + }; + +TDmaTestInfo TestInfo = {0, 0, 0, 0, NULL, 0, NULL, 0, NULL}; + + +EXPORT_C const TDmaTestInfo& DmaTestInfo() +//... + { + return TestInfo; + } + +

Test +application use cases

The DMA test application is used to +test:

one shot single buffer transfer
one shot double buffer transfer
one shot scatter/gather transfer
streaming single buffer transfer
streaming double buffer transfer
streaming scatter/gather transfer

The DMA test application can be used on both reference hardware +platform and software simulated DMA.

Limitations

The DMA test application has the following known limitations:

only supports one shot and streaming data transfer
many parameters such as the number of buffers, the transfer +size and the number of fragments are fixed
does not support performance measurements like CPU usage, setup +time and transfer time
does not support memory to peripheral data transfer
does not support SMP related testing like allocating DFC on +same core or different core.