Collapse all Symbian^3 Product Developer Library

Platform Specific Layer Validation

Describes the test code to validate a port of the MMC Controller.

There are three stages involved in testing a port of the MultiMediaCard controller. The first stage tests the controller in isolation; subsequent stages test an additional area of functionality.

All three stages involve text shell based test programs and test drivers, and therefore these tests can be run by just building a text shell ROM. You can also run tests on the Emulator.

Testing the controller in isolation

MMCTEST.EXE tests the MultiMediaCard controller in isolation, at the controller’s client interface level. Since the controller’s client API is a kernel side interface, this requires a test driver, D_MMCIF.LDD, as well as the test program itself.

This is not a 'go/no-go' type test, but is a test utility that can perform a small variety of operations. These are selected a simple interactive way by pressing appropriate keys.

Building MMCTEST.EXE and D_MMCIF.LDD

The source and header files needed to build MMCTEST.EXE can be found in ...\e32utils\pccd; the mmp file is ...\e32utils\group\mmctest.mmp.

The source and header files needed to build the test driver D_MMCIF.LDD can be found in ...\e32utils\pccd; the mmp file is ...\e32utils\group\d_mmcif.mmp.

You need to build MMCTEST.EXE for the appropriate CPU target architecture (e.g. ARMI,THUMB etc.); you need to build D_MMCIF.LDD for the appropriate platform (e.g. MINT).

Include both of these components in a ROM

Running the tests

Run MMCTEST and perform the following suggested sequence:

Without a card inserted, power up the stack by pressing P, and check that it reports that no card is present.
Insert a card, power it up, and check that it reports that a card is present.
Now that the card is powered up, read the card info by pressing C, and check the data returned about the card against the expected card data, by referring to the datasheet for the card.
Read the first sector of the card by pressing M.
Now read a few more sectors by pressing the space bar.
Test writing to a sector: while still viewing a sector, edit a part of this, by using the direction keys and typing in a hex number. Now save the change by pressing ESC, followed by Y. Now navigate to the same sector again and check that it displays the new contents of the sector.
Quit the test by pressing Q.

Testing the controller with the media driver and the local media sub-system

DRVTEST.EXE tests the MultiMediaCard controller in conjunction with the media driver and the local media sub-system, in effect accessing the card as a local drive. This requires a kernel side test driver D_DRVIF.LDD as well as the test program itself.

This is not a 'go/no-go' type test, but is a test utility that can perform a small variety of operations. These are selected a simple interactive way by pressing appropriate keys. It is used to test that card initialization and single block read and write requests are performed successfully.
T_ATADRV.EXE tests that card initialization and simple read and write requests succeed. It also tests multi-block read/write operations, format requests, accessing the device following a media change event, and a machine power down event.

This is a 'go/no-go' type test. If this test succeeds, you can have fairly high confidence that the F32 test suite will run successfully.

Building DRVTEST.EXE, D_DRVIF.LDD, and T_ATADRV.EXE

The source and header files needed to build DRVTEST.EXE can be found in ...\e32utils\pccd; the mmp file is ...\e32utils\group\drvtest.mmp.

The source and header files needed to build the test driver D_DRVIF.LDD can be found in ...\e32utils\pccd; the mmp file is ...\e32utils\group\d_drvif.mmp.

The source and header files needed to build T_ATADRV.EXE can be found in ...\e32test\pccd; the mmp file is ...\e32test\group\t_atadrv.mmp.

You need to build DRVTEST.EXE for the appropriate CPU target architecture (e.g. ARMI,THUMB etc.)

You need to build D_DRVIF.LDD for the appropriate platform (e.g. MINT)

You need to build T_ATADRV for the appropriate CPU target architecture (e.g. ARMI,THUMB).

Include these components in a ROM.

Running the DRVTEST test

Run DRVTEST and perform the following suggested sequence:

Without a card inserted, power up the stack by pressing P, and check that it reports that no card is present.
Insert a card, power it up, and check that it reports that a card is present.
Now that the card is powered up, read the card info by pressing C, and check the data returned about the card against the expected card data, by referring to the datasheet for the card.
Read the first sector of the card by pressing M.
Now read a few more sectors by pressing the space bar.
Test writing to a sector: while still viewing a sector, edit a part of this, by using the direction keys and typing in a hex number. Now save the change by pressing ESC, followed by Y. Now navigate to the same sector again and check that it displays the new contents of the sector.
Quit the test by pressing Q.

Running the T_ATADRV test

Run T_ATADRV and follow the on-screen instructions. Check that the test runs to the end with no errors.

Testing using the F32 test suite

The final test stage is to run the entire file server test suite on a card drive.

To perform these tests:

build a text shell ROM that contains the F32 test suite, i.e. build the ROM with the option:
```
-t=f32tests
```
boot the test machine into the text shell.
launch the F32 automatic tests and check that all of the tests run without error. Use the command option "-d" to set the default drive, for example:
```
RUNTESTS F32TEST.AUTO.ARMI.BAT -d d
```

Emulator-based tests

It is possible to emulate a user opening and closing the MMC drive door, replacing and removing the MMC card, and assigning a password to an emulated MMC card. This is important so that you can test:

how an application behaves when the MMC card, from which the application is running, is removed and/or swapped
how an application behaves when it is reading and writing data to and from an MMC card
that data stored on an MMC card is not lost or corrupted during MMC drive events
that MMC card locking and password notification works correctly.

The platform independent layer of the MuiltiMediaCard controller, as its name implies, is common to all platforms, including the emulator. However, the emulator provides its own implementation of the platform specific layer.

The emulator does not provide access to any kind of MultiMediaCard hardware. Instead, the memory area of each emulated card is represented by a file, a .bin type file in the Windows system temp directory, on the host machine. The MultiMediaCard emulator emulates a single stack containing two separate cards, the first in slot 0, and the second in slot 1. Each emulated card has an associated .bin file on the host machine. As the emulator only supports the swapping of cards in slot 0, there are two .bin files, one for each of the two emulated MMC cards in slot 0. There is no support for card swapping on slot 1, and therefore this has only one .bin file.

This means that all the test programs described can be run on the emulator, and they will exercise the platform independent layer code in the same way as on real target hardware. It also means that call entries to, and exits from platform specific layer code can be traced, and may be useful for debugging problems on real hardware, and to help understand how the controller operates.

The code for the emulator specific layer code can be found in ...\wins\specific\mmc.cpp.

Parent topic: MMC Porting Implementation Tutorial