Windows 9X/NT & CE

MediaQ, Inc. Proprietary and Confidential

Revision 1.02 July 21, 2000

1

Windows 9X/NT & CE

Diagnostic Tools

Written by

Benedictus Tjandrasuwita



2

Table of Contents

1. Introduction ......................................................................................................................

2. Product Description..........................................................................................................

3. Target Builds and Utility Bring-up.....................................................................................

4. Graphical User Interface....................................................................................................

5. Host-Client Communication...............................................................................................

6. Script Language................................................................................................................

6.1 Script GUI ............................................................................................................................................... 6.2 MQSL Syntax..........................................................................................................................................

6.1.1 Example1: Rectangle Fill.......................................................................................................... 6.1.2 Example2: Screen to screen BLT............................................................................................. 6.1.3 Example3: Color bitmap to screen BLT..................................................................................

7 Diagnostics ......................................................................................................................

7.1 Power Management Tool ........................................................................................................................ 7.2 PLL Programming and Test Tool ...........................................................................................................

8 Conclusion.......................................................................................................................

9 Reference.........................................................................................................................



3

Table of Figures Figure 1. MediaQ Logo .......................................................................................................................................... Figure 2. Main Page................................................................................................................................................ Figure 3. Device Register Menu Listing............................................................................................................... Figure 4. Graphic Controller ................................................................................................................................. Figure 5. Host Menu Option.................................................................................................................................. Figure 6. Client Menu Option................................................................................................................................ Figure 7. Additional Features................................................................................................................................. Figure 8. FRC Pattern ............................................................................................................................................ Figure 9. FRC Weight............................................................................................................................................. Figure 10. FRC Dither ........................................................................................................................................... Figure 11. FRC Logic............................................................................................................................................. Figure 12. File Save Feature .................................................................................................................................. Figure 13. Host-Client Configuration 1 ............................................................................................................... Figure 14. Host-Client Configuration 2 ............................................................................................................... Figure 15. Communication Icon Status................................................................................................................. Figure 16. Script GUI ............................................................................................................................................. Figure 17. Power State Diagnostics...................................................................................................................... Figure 18. PLL Programming................................................................................................................................



4

1. Introduction The MediaQ Windows 9X/NT & CE Diagnostic Tools is also known as the “MQDT” window utility. The utility has a “MediaQ” logo, which is a trademark of MediaQ Incorporated. The company enforces all copyrights of the logo as well as the utility. As a diagnostic tool, MQDT currently support the following MediaQ ASIC product:

• MQ200 As a company, MediaQ is also making the commitment to continue its support to upgrade the MQDT utility for future products of the company.

2. Product Description The MQDT is a window based debugging and diagnostic tool designed and written solely for Windows 9X, NT and CE (32-bit) operating systems. As a 32-bit application, MQDT has a single source code that can be compiled for various different target platforms. Unfortunately, due to the nature of the CE target platforms, MQDT cannot share or guarantee a single executable can run on all the CE-based platforms. A CE target platform may have a different processor and obviously machine language than the others. Nonetheless, the current release of Microsoft Windows CE SDK does not allow a software developer to create a single executable for the various CE target platforms. MQDT is designed to support the most basic functionality of debugging and that is to read and write data to either the target device registers, or target embedded display memory. Other than the basic read-write functionality, MQDT also provides descriptive register pages for quick and easy references to all the device registers. To improve quality and test efficiency on the new features, MQDT has the so-called emulation mode to duplicate the register and display memory space on a RAM buffer rather than the actual device. In some cases, the emulation mode can also be used to test the hardware functionality without affecting the device directly. Other features of MQDT are listed below in each of the version releases of the product. MQDT built-in diagnostic applications are described in section 5.0. As a complete software product, MQDT offers the following list of features:

• Register read-write • Display memory read-write • Save registers to a file • Emulation (debug) mode • Module specific register pages • FRC Pattern, Weight and Dither • FRC Logic (emulation for internal FRC module block) • Host-Client configuration • Set or change PLL clock reference • Set or adjust register read (or update) timer • Set or change base addresses of register and display memory space • Switch display for controller 1 registers versus controller 2 registers • Scripting capability for register read/write, 2D, and diagnostic commands • General help menu



5

3. Target Builds and Utility Bring-up The MQDT comes in at least two separate and independent executables for the two different versions of Windows operating systems, Windows 95/NT and CE. Both executables require no command line arguments to bring up. However, the following optional arguments can be used in bringing up the MQDT from the command line:

Mqdt200 <mode> <com> <special>

mode = client or host; com = com1 or com2; special = hide (runs in background). Once copied to the target system hard disk, MQDT should be relatively easy to invoke from the console. Copying the Windows 9X/NT executable (MQDT32.exe) to the target system is as easy as a standard file copy procedure. On the other hand, loading the CE executable (MQDTCE.exe) may require binding the application with the kernel and then utilizes the cesh to download the image via the parallel port or Ethernet. Other way of loading the application would be through the Mobile Services that utilizes the serial port or Ethernet to run the Microsoft ActiveSync utility. These Microsoft tools are stand-alone tools that come with the Microsoft Visual C++ for Windows CE.

4. Main Graphical User Interface The first page on the MQDT is the Main Page, and as the first page displayed at runtime, the page is designed to provide the user with the most flexible and easy-to-use debugging features. The most basic debugging feature would be the edit fields for reading and programming device registers, pixel and memory clocks, as well as display memory (Figure 2). Other debugging features would be to specify the increment units for the indexes, data, as well as clock frequency. The MediaQ logo on the Main Page is not only a trademark for MQDT but also a pushbutton option to change the Main Page configuration settings (available on next release version). The options included in the configuration settings are register read-write data size, operation types (read only, write only, or read-write), as well as multiple data programming on display memory. Figure 1. shows the MediaQ logo on the Main Page for configuration settings.

Figure 1. MediaQ Logo



6

Figure 2. Main Page

There are other similar pages that offer the same read and write capabilities on the device registers. They are created to group the device registers based on modules and common usage. For example, all the PMU registers are placed on a separate page than the MIU registers, and similarly the Flat Panel registers. These pages also contain the register names and index numbers for quick reference of the hardware documents. All device specific registers are listed under Display->Device Registers menu option and these are the current available choices:

• Power management register (PMU) • CPU interface register (CIF) • MIU interface register (MIU) • Interrupt register (INT) • Graphic controller register (GC1 & GC2) • DAC lookup table register (DAC) • 2D graphic engine register (GE1 & GE2) • 2D color Pattern register (GEC1 & GEC2) • Flat panel, FRC pattern, and FRC weight register (FP)



7

The actual snap shot of the device register listing on the utility is shown on Figure 2. Every MQDT page has the same set of pushbutton options at the bottom of the page. They are options to switch to the previous page (<= Prev), save the page contents to a file (Save), communication status (Off, Ready, or Link), and fast page update button (Update), and finally switch button for next page (next =>).

Figure 3. Device Register Menu Listing

Figure 4. shows a typical register page that contains device register description, indexes, and data fields. Non-highlighted edit fields are reserved for future use or read only registers.



8

Figure 4. Graphic Controller

Depending on the device type and mode (i.e. Host or Client), MQDT configures and enables the appropriate pages and menu options for the target device. For example, running MQDT in a Host mode will enable only standard and Host specific menu options (Figure 5). In vice-versa, running MQDT in a Client mode will enable only standard and Client specific menu options (Figure 6). MQDT also accept all-standard keyboard interface and Window control keys (i.e. shortcut keys).

All MQDT additional features other than the basic register read-write and certain configurations are listed as the following menu options: • Host is a menu option to configure the MQDT as the remote debugger of the device. It relies on serial port for

communication with the target Client debugger. This option allows the user to enable the so-called Host-Client configuration. For further information regarding the Host-Client configuration, please see section 3.1.

• Client is a menu option to configure the MQDT as the target debugger running on the target platform. It relies on the serial port to communicate with the Host MQDT. This option allows the user to enable the Host-Client configuration from the target system.

• Clock PLL Setup is a menu option to display and modify the system (calculated) clock input reference frequency. This option enables MQDT to set its internal clock reference for calculating pixel and memory clock frequencies. The dialog box has default button to set the default reference clock frequency. OEM should determine the so-called default clock frequency.



9

• FRC Pattern Setup is a menu option to configure the rows and columns of FRC Pattern data. The option allows user to scroll the FRC pattern horizontally as well as vertically. This option is often used to tune flat panel FRC response.

• Timer Setup is a menu option to change the register read timer from its default setting of 500 milliseconds. MQDT uses the same timer to update the FRC page when the automatic tile pattern test is enabled. The timer should also indicate how fast the data are transmitted through the communication port(s) in a Host and Client configuration. The dialog box has default button to set the timer.

• Base Address is a menu option to change the register and memory base addresses from its default settings of 0x3E00000 (register base address) and 0x2000000 (display memory base address). MQDT allows the user to change the base addresses on the fly. User must make sure that these addresses are set correctly before modifying the registers. The dialog box has default button to set default base addresses. (NOTE: on PCI-based platforms, MQDT relies on the user to specify base addresses of the device. Hence, it is not automatically configured.)

• Display Controller 2 is a menu option to display Controller 2 registers. When selected, all Controller 2 registers on the device are displayed and accessible through the GUI interface.

• Emulation Mode is a menu option to enable read-write operations from dynamic memory allocation (RAM buffer) rather than directly from the device registers.

Figure 5. Host Menu Option

The Host MQDT has the following mode specific features: • Update Page is a Host menu option to send a command to the Client for a standard page update. The Client will

respond by sending the updated register data. Another quick way to do this is to use the Update pushbutton at the bottom of the page.

• Periodic Updates is a Host menu option that automatically enables the Client’s Periodic Reads option. Once activated, the Client will continuously sending data to the Host at the frequency defined by the Timer Setup.

• Terminate Target is a Host menu option to terminates the Client MQDT. • Reset Target is a Host menu option that resets and re-syncs the Host with the Client MQDT. Host MQDT

automatically issues the Reset Client command at the initial bring-up of the COM Port. • Open COM Port: COM1 is a Host menu option that initiates the Host-to-Client handshaking protocols for

remote debugging. This particular option relies on the serial COM1 port for broadcasting the protocols. (please see section 5 for more detailed description on the handshaking protocols)

• Open COM Port: COM2 is another Host menu option that initiates the same handshaking protocols as the above option, except for the port that broadcasts the protocols.



10

Figure 6. Client Menu Option

The Client MQDT has the following mode specific features: • Periodic Reads is a Client menu option for reading and updating the register values periodically. The time

intervals programmable through the Timer Setup option. • Open COM Port: COM1 is a Client menu option that initiates a Client-to-Host handshaking protocols for

remote debugging. It relies on the serial COM1 port for broadcasting the protocols. Section 5 describes more detailed description on the handshaking protocols.

• Open COM Port: COM2 is another Client menu option that also works the same way as the above option, except for the port that broadcasts the protocols.

Figure 7. Additional Features

Other than the above listed features, MQDT has the following additional features: • FRC Pattern is a built-in GUI feature that loads the FRC pattern on the device registers as well as displaying

them on the console. This feature allows the user to test the different pattern and dynamically changes the programming whenever necessary. The edit fields are design for user to easily modify individual pattern value (or nibble) (Figure 8).

• FRC Weight is a built-in GUI feature that loads the FRC weights on the device registers as well as displaying them on the console. This feature allows the user to test the different values and change them dynamically when necessary. Similarly, the edit fields are design for user to easily modify individual weight value or bit (Figure 9).



11

• FRC Dither is a built-in test feature that can emulate the Flat panel dither logic. This test is commonly used for verifying the built-in hardware dither logic. User has the option of using BMP, ASCII, or simply manual input data to test the logic (Figure 10). The output of this dithering algorithm can be in ASCII or BMP. Please note when either RIE[6],GIE[6],or BIE[6] is enabled , MQDT will use error algorithm 1 (multiply by 2) to calculate the error phase for that color field. Similarly, if RIE[7],GIE[7], or BIE[7] is enabled, then MQDT will use algorithm 2 (scramble) . If both are set, then algorithm1 will be used.

• FRC Logic is another built-in test feature that can emulate the FRC hardware logic. The test can generate two-bit RGB output data to compare with the actual hardware output data. Like the FRC dither, this feature is commonly used for verifying the hardware logic. The feature accepts manual, ASCII, as well as dither input (Figure 11).

• Pixel and Memory Clocks are provided to program and tests dual display modes. There are three PLL to choose for the two Pixel clocks (clk1 and clk2) and a memory clock (mclk). The utility can calculate the register values for the desired clock frequency along with actual programming of the correct PLL. For further information on how to program the clocks properly, please see each device specification (Figure 2).

• File Save As is provided to capture the MQDT current page data into a file. User can use this feature from the Client as well as from the Host side. Normally this feature will overwrite the file, unless the “append to file” feature is selected (available on version 1.1 and later). See Appendix A for output sample and Figure 12 for the dialog box.

• File Save All is a similar feature to the File Save As, except that the MQDT will capture all the current data from all the MQDT pages. Note: this option is currently available only at the Client side.

Figure 8-9. FRC Pattern and Weight



12

Figure 10-11. FRC Dither and Logic



13

Figure 12. File Save Dialog

5. Host-Client Configuration One “must-have” feature on MQDT is the Host-Client configuration. This feature allows the user to use MQDT to debug a target system remotely. In this case, the remote system running Windows 9X/NT or CE operating systems must run MQDT in Host mode; then, the Target system can receive the commands while running MQDT in Client mode. This configuration improves the user flexibility and effectiveness in probing, debugging, and testing the target systems. Moreover, with the Host-Client configuration, the target system does not have to maintain or retain the display contents during the session. This way the user can alter, change, or even restore the target display remotely. To enable the Host-Client configuration, a remote system running MQDT in a Host mode can first open the COM port to initiate the serial port protocols (Figure 5). Then, a target system running MQDT in a Client mode can connect to the remote system by enabling one of its COM ports (Figure 6). At most times, the order of who initiates the protocols will not matter; the two sides should still be connected at the end. Once the communication is established, the remote system can send commands to the target system or vice-versa. The following are the two Host-Client configurations that MQDT supports:



14

Figure 13. Host-Client Configuration 1

Configuration 1 (Figure 13):

• Remote system: Windows 9X/NT (Host mode only) • Target system: Windows CE (Client mode) • This feature is SUPPORTED on current release of MQDT.

Figure 14. Host-Client Configuration 2

Configuration 2 (Figure 14):

• Remote system: Windows CE (Host mode) • Target system: Windows CE (Client mode) • This feature is NOT SUPPORTED on current release of MQDT.

MQDT provides an online indicator for the serial port connection status, and it should be different than just the checkmark on the on the menu option. The online indicator is shown at the bottom of each MQDT page. It has three states: OFF, READY, and LINK (Figure 15).

Figure 15. Communication Icon Status

To disengage the serial port communications and disable the Host-Client configuration, user can always deselect the Open COM port option from either the Host or Client side, or better yet, switch MQDT from Host to Client on the remote system.



15

6. Script Language

MQDT version 2.0 and later provides scripting capability for various applications such as register programming, hardware feature verification, as well as diagnostic tests. The script language chosen for MQDT is MediaQ Script Language (MQSL) which is based on the Tool Command Language (TCL) command parser. TCL is a UNIX based parser that runs on most Windows-based operating system. For more information on the TCL language itself and its programming reference, please see Ref. 1.

The biggest advantage of using MQSL scripts on MQDT would be to provide the user with an easy and flexible mean of creating and changing test applications on the fly. However, due to the complexity of the script parser itself, MQDT can only execute scripts from NT-based Host system. On the other hand, minimal performance hit should be expected when running the script via the serial port communication (Host-Client configuration). In this case, the serial port communication is the bottleneck.

6.1 Script GUI

MQDT is dedicating a GUI page for script loading as well as command-line execution. User has the option of loading the script locally or remotely upon execution, and likewise for the command-line option. Local means the file must exist at the local machine where MQDT is running, or it must exists exist at remote machine for Remote option. These local and remote options also determine which parser to run (local or remote).

Script files or commands can also be loaded or executed at any number of iterations. The number of iterations is programmable on MQDT (shown on Figure 16). At runtime, user has the option to abort the iterations by hitting the cancel push-button . A pause push-button is also provided to stop the iteration loop temporarily.

When loading script files through MQDT, user can use either forward or backslash notation in the path; however, when using the command line, user must use forward slash (‘/’) to specify the path. This is required because the TCL parser is a UNIX based parser compared to other operating system based parser.

A new feature has been added in MQDT version 2.0 to improve the command interpreter’s ease of use, and that feature is script browsing. The “Browse” button allows the user to search and find the right script for the right test at the click of the button. Note: command interpreter can run *.sl scripts and load *.tcl scripts only.

6.2 MQSL Syntax

MQSL is design to provide users with generic script commands or instruction that can be use to debug, verify, and run diagnostic tests directly on MediaQ devices. The language is derived from TCL and expanded to fit our needs and requirements for debugging, validation, as well as diagnostics. The list of reserved words or instructions that makes up the MQSL language syntax are

• Comment: //, # • Variables: var0 - var5 (SH model), var0 – var15 (BIU targets) • Interrupt Counts: int0, int1, …, int31 • Instructions: wfm, devrd8, devrd16, devrd32, devwr8, devwr16, devwr32, testmsg, emit • Control Instructions: While, Begin, End, If, Include, Target, Exit • Math Operand: +, -, *, = • Bit-wise Operand: &, |, ^, <<, >>



16

• Logical Expression: ==, >, <, != • Low-level DLL Interface Functions: mqsl_begin, mqsl_end, mqsl_drd, mqsl_dwr, mqsl_wfm • Run-time Commands: mqslver, target, setmode, setlib, mqbase, parse, run, perror, help, pproc,

runshell, parseall, runemuall, quit, exit

Supported target platforms: SH3/SH4 (assembly code), SHX, NEC, TOS, SA, PCI, MC, and EMUL.

Figure 16. Script GUI

The following are brief descriptions and examples of MQSL and their usage syntax: 1. Variable Declaration, Initialization, and Assignment

Syntax: var<index> <op> <data> Syntax: var<index> <op> var<index> var: reserved variable with index number data: can be decimal or hex operand: “=” sign i.e. var1 = 1234

var2 = 0x12ABCDE



17

** All data type must be 32-bit maximum.

2. Interrupt Count (Read Only) Syntax: int<index> int: (reserved) interrupt count with associated interrupt number. Index is the associated interrupt number.

** This interrupt count should only be used in a logical expression (see no 13). 3. Math and Bit-wise operations on Registers

Syntax: var<index> <op> var<index> Syntax: var<index> <op> data reg<index>: CPU register data: absolute values (decimal or hex) op: +, -, *, &, |,^,<<,>> i.e. var1 + var2

var2 * var3 var3 & var4 ** Bit-wise operation result is placed in the first operand. (i.e. var1 + var2 equals to var1 = var1 + var2).

4. Begin Statement

Syntax: Begin ** Contains machine/device specific initialization (if any)

5. End Statement Syntax: End

** Contains machine/device specific clean-up procedure (if any)

6. Comment Line Syntax: // <comment> or # <comment> The “//” comment line will appear on the output file of a parse command; whereas the “#” command line will not.

7. Include Statement

Syntax: Include <include-file> include-file: full path name (must use forward slash instead of back slash in the path name) This command includes one or more MQSL script file(s) in another. It functions or behaves the same way as the “include” statement in C programming language.

8. Const Statement

Syntax: const <const_name> <data> const_name: defined name for the data data: can be values or predefined variables ( var0 – var5 ) In general, this instruction defines constants. A good programming practice is to declare constants in a separate header file.

9. Target Statement

Syntax: Target { target_list > } { commands } target_list: target platforms seperated by space. i.e. { sh4 emul mqdt-ce } commands: any MQSL commands This command specifies target specific lines of code.

10. ISR Statement



18

Syntax: ISR { <type> } { <body >

} type: interrupt types (0 to 31 max.) body: body statements (see no.13) ** This instruction defines interrupt service routines, which must be declared outside of the main body (exclusive to Begin-End statements). So far, there are 32 different interrupts supported in the BIU interface.

11. If Statement

Syntax: If { <logical expression> } { <body> } logical expression: see no. 14 body: see no. 13 ** This command is the equivalent of the C/C++ “if-statement”. No “else-statement” is supported here.

12. While Statement

Syntax: While { <logical expression> } { <body> } logical expression: see no. 14 body: see no. 13 MQSL currently supports nested while loops up to 3-level deep. Anything more than that, the parser cannot generate code correctly on certain target platforms.

13. Body Statement

Syntax: <statement1> <delimiter> <statement2><delimiter> statement: can be any of the supported instructions or control statements delimiter: “;” i.e. (see no. 3)

14. Logical expression

Syntax: <item1> <op> <item2> item1, item2: can be one of the reserved variables or absolute values (decimal/hex value only) op: >, <, ==, !=

15. MediaQ Device Write Instructions

8-bit write syntax: devwr8 <space> <address> <data> 16-bit write syntax: devwr16 <space> <address> <data> 32-bit write syntax: devwr32 <space> <address> <data> space: r – register, f – frame buffer space, p – processor space (base address: 0) address: offset from the base address (absolute values or reserved variables only) data: reserved variables or absolute values (decimal or hex)

16. MediaQ Device Read Instructions

8-bit read syntax: devrd8 <space> <address> var<index> 16-bit read syntax: devrd16 <space> <address> var<index> 32-bit read syntax: devrd32 <space> <address> var<index> space: r – register, f – frame buffer space, p – processor space (base address: 0) address: offset from register base address (absolute values or reserved variables only) var: reserved variables (var0,var1,var2,etc)



19

17. MediaQ Wait For Mask Instruction Syntax: wfm <address> <op> <mask> <data> { <lower limit> <upper limit> } address: offset from register base address (absolute values or reserved variables only) op: !=, ==, >, >=, <, <= mask: data to mask the value read from the specified address data: the expected value to be compared with the masked register value. If the comparison is TRUE, then the function returns. lower limit: this is an optional parameter to specify the lower bound of the data range. This option can only be used with the >= or <= operators, and must be combined with the upper

limit as well. upper limit: like the lower limit, this option can only be used for the >= and <= operators. The use of the combined lower and upper limits are for FIFO checking where this logic should apply: lower limit = max, lower limit < range < upper limit.

** This instruction will enhance MQDT remote-client performance

18. MediaQ DMA Write Buffer Instruction Syntax: dmawrbuf <index> <data> <buffer=m> index: index to buffer. Currently, BIU platform only supports indexes that begins from 0. This index is auto

incremented by the low-level function. Currently, the DMA buffer is limited to 64x32 entries. data: 32-bit data to store in the buffer. buffer: m – master memory, sm – slave memory, si – slave io, sc – slave configuration. Default is master

buffer. ** This instruction is supported in BIU interface only.

19. MediaQ DMA Read Buffer Instruction Syntax: dmardbuf <index> <data> <buffer=m> index: index to buffer. Currently, BIU platform only supports indexes that begins from 0. This index is auto

incremented by the low-level function. Currently, the DMA buffer is limited to 64x32 entries. data: 32-bit data to read from the buffer. buffer: m – master memory, sm – slave memory, si – slave io, sc – slave configuration. Default is master

buffer. ** This instruction is supported in BIU interface only.

20. MediaQ DMA Write Burst Instruction Syntax: dmawrburst <space> <address> <count> space: r – register, f – frame buffer space, p – processor space (base address: 0) address: offset from the base address. The space field determines the base address, which automatically added

to this address offset at the low-level function. Currently, the DMA buffer is limited to 64x32 entries. count: 32-bit count to fetch the data from DMA buffer. ** This instruction performs burst write from the DMA buffer to the device at the specified count. This instruction is supported in BIU interface only.

21. MediaQ DMA Read Burst Instruction Syntax: dmardburst <space> <address> <count> space: r – register, f – frame buffer space, p – processor space (base address: 0) address: offset from base address. Base address is determined from the space field and automatically added to

this address field at the low-level function. Currently, the DMA buffer is limited to 64x32 entries. count: 32-bit count to fetch the data from DMA buffer. ** This instruction performs burst read from the device to DMA buffer at the specified count. Previous buffer contents will be overwritten. This instruction is supported in BIU interface only.

22. Test Message Instruction



20

Syntax: testmsg <addr> <edata> <data> addr: address field edata: expected data data: read data ** This instruction prints the test result message at runtime. The instruction will print address, expected data, and read data as they are specified in the command line arguments. Programmers can use variables to specify command arguments.

23. Emit Statement Syntax: emit “text” or emit {text} Write text string directly to output file. This command is interpreted only for code generation.

24. Exit Statement Syntax: Exit <mode> mode: pass,fail,none Exit MQSL script file and display message PASS or FAIL based on the mode settings.

25. Low-level DLL Interface Functions Mqsl_begin: DLL initialization function Mqsl_end: DLL exit function Mqsl_wfm: DLL wait for mask function Mqsl_dwr: DLL device write function Mqsl_drd: DLL device read function Mqsl_biu_wrbuf: DLL dma write buffer Mqsl_biu_wrburst: DLL dma write burst Mqsl_biu_rdbuf: DLL dma read buffer Mqsl_biu_rdburst: DLL dma read burst Syntax: please see Appendix A. for the DLL header file

26. Run-time Commands • mqslver: command to display MQSL version and environment settings. • target: command to retrieve or set target platform

Usage: target <platform> • setmode: command to set initialization mode or environment settings

Usage: setmode <mode> <option> Modes and options : Destination output memory (destmem): Video (screen) or System (memory) Memory Initialization (initmem): One (0xffffffff) or Zero (0x00000000) Destination OS (destosi): DOS or Unix (execute DOS to Unix text conversion) WFM Command (wfmcmd): On (parse wfm command), Off (skip wfm command). Interrupt (intr): On (manual ISR insertion required), Off (auto dummy ISR insertion), Null Burst: On (write/read burst enabled), Off (write or read burst disabled). Data path: 32bit (default, little-endian), 16bit (little-endian), 32bitswap (big-endian), and 16bitswap (big-endian)

• setlib: command to set DLL name Usage: setlib <library name>

• mqbase: command to retrieve or set base addresses Usage: mqbase <type>

• parse: command to parse MQSL script and generate target specific platform code Usage: parse <script> <target> <output>

• parseall: command to parse MQSL scripts and generate target platform code in a batch mode Usage: parseall <list file> <target>

• run: command to execute MQSL script



21

Usage: run <script> <target> • runemuall: command to execute MQSL script in a batch mode

Usage: runemuall <list file> <initmem_value> • perror: command to print debug or error messages.

Usage: perror • help: command to print help menu

Usage: help <command> • pproc: command to print procedure

Usage: pproc <proc name> • runshell: command to start interactive shell that will log user commands in the runshell.log file.

Usage: runshell • quit: command to exit runshell (interactive shell) • after: time delay in milliseconds.

Usage: after <msec> • exit: command to exit MQSL shell

Usage: exit

NOTE: All MQSL syntax are case-sensitive unless specifically noted.

6.2.1 MQSL Script Examples The following are MQSL script examples

6.2.1.1 Example 1 : Rectangle Fill Include $HOME/mq100.sl Begin // set up common registers devwr32 r $BASE_ADDRESS 0; devwr32 r $SRC_DEST_PITCH 0x04000400; // rectangle fill devwr32 r $DEST_XY 0x00800010; devwr32 r $WIDTH_HEIGHT 0x00050020; devwr32 r $FG_COLOR 0x000000ff; devwr32 r $DRAW_CMD 0x000001cc; // wait for ge not busy wfm $DRAW_STATUS == 0x00010000 0x00; End

6.2.1.2 Example 2 : Screen to screen BLT Include $HOME/mq100.sl Begin // set up common registers devwr32 r $BASE_ADDRESS 0;



22

devwr32 r $SRC_DEST_PITCH 0x04000400; // S-to-S BLT devwr32 r $SRC_XY 0x00000000; devwr32 r $DEST_XY 0x00100000; devwr32 r $WIDTH_HEIGHT 0x00050020; devwr32 r $DRAW_CMD 0x000002cc; // wait for ge not busy wfm $DRAW_STATUS == 0x00010000 0x00; End

6.2.1.3 Example 3 : Color bitmap to screen BLT Include $HOME/mq100.sl Begin // set up common registers devwr32 r $BASE_ADDRESS 0; devwr32 r $SRC_DEST_PITCH 0x04000400; // M-to-S, color bitmap devwr32 r $DEST_XY 0x00000000; devwr32 r $WIDTH_HEIGHT 0x00010010; devwr32 r $OFFSET_REG 0x00000000; devwr32 r $DRAW_CMD 0x000022cc; // write bitmap data var1=0; While {var1 < 4} { devwr32 r $SRC_IMAGE_DATA 0x12345678; var1 + 1; } End

7. Diagnostic Applications

MQDT version 2.0 and later provides standard, diagnostic applications such as memory, RAMDAC, register, and PLL tests. Some of the applications such as memory and RAMDAC tests are simply provided in MQSL format. The MQDT release package should include these test scripts. Other applications will have a dedicated page on MQDT. For further description on these diagnostic tests, please see Ref 2.

7.1 Power Management Tool

This tool allows the user to switch power management states on the fly through MQDT. There are four power states (D0, D1, D2, and D3) that most MediaQ devices, including MQ100, have in their specifications, and these power states are very important to test because the device functionality depends on these features to work properly. The tool has given the user flexibility to enable or disable individual hardware feature block in each power state, and programs the settings on the fly (Figure 17).



23

Figure 17. Power State Diagnostic

7.2 PLL Programming and Test Tool

This tool allows the user to program and test the PLL output frequency at runtime. There are pins available to probe the output frequency as well as register programming to enable the output pin itself. The tool is multi-purpose, but yet it is best used to program the PLL parameters for both Graphic Controllers. The tool can read the current PLL settings, change or force certain parameters to a fix value, and then reprogram the parameters for the same frequency. This feature is important to find the best programming values for a certain frequency (Figure 18).



24

Figure 18. PLL Programming

8. Conclusion The goal of adding diagnostic routines in a utility such as the MQDT is not only to minimize the human error when debugging a complex device, but also to increase effective debugging time. The MQDT is created solely for the purpose of debugging and testing all MediaQ products. The utility will be maintained and upgraded by the MediaQ software group.



25

9. Reference 1. John K. Ousterhout, TCL and the Tk Toolkit, Copyright 1994 Addison-Wesley Publishing

Company. 2. Murty Bhavana, MQ100 Evaluation/Debug Board Specification, May 5, 1998.



26

Appendix A

Main page saved file: Base 000000 >> Index 0000 = 00000000 Base 000000 >> Index 0000 = 00000000 Base 000000 >> Index 0000 = 00000000 Base 000000 >> Index 0000 = 00000000 Base 000000 >> Index 0000 = 00000000 Base 000000 >> Index 0000 = 00000000 Base 000000 >> Index 0000 = 00000000 Base 000000 >> Index 0000 = 00000000 FB 000000 = 00000000 Prog = OFF Clk Step = 1.00 Index Step = 0001 Data Step = 00000001 CLK1 = 0.00 CLK2 = 0.00 MCLK = 0.00



27

Appendix B

-------------------------------------------------------------------------- MediaQ Diagnostic Tools README File (c) Copyright 1998 MediaQ, Inc. All Rights Reserved. Updated on 9/20/98 ------------------------------------------------------------------------- README TABLE OF CONTENTS: 1. Installation 1.1 Windows NT 4.0 and later 1.2 Windows CE 2.0 and later 1.2.1 Built-in Kernel 1.2.2 Mobile Services (ActiveSync) -- recommended way 1.2.3 PCMCIA / Flash Card Services 2. MSVC 5.0 Build Procedure (available for OEM use only) 3. Troubleshooting 4. Additional Information _________________________________________________________________________ 1. Installation Copy the MQDT.EXE to your WinNT or WinCE system using the procedure listed on either section 1.1 or 1.2, and then the program is ready for use. 1.1 Windows NT 4.0 and later Use the standard copy command or Explorer function of "Drag and Drop" when copying MQDT.EXE to your install directory. Make sure all MQDT DLL’s I

are copied to the install directory along with the MQDT.TCL file. Finally, run MQDT.exe using this command: mqdt host comX where comX should indicate the connected com port. Note: MQDT supports connection via com1 or com2 only.

1.2 Windows CE 2.0 and later 1.2.1 Built-in Kernel

Build the kernel for target platform. Copy MQDT.EXE (use the version that matches the target platform processor type) to the “..\WINCE20\release\” area. Edit common.bib file to include the following line under MODULE section: mqdt.exe $(_FLATRELEASEDIR)\mqdt.exe NK Also, add the following line under FILE section: Mqtile.txt $(_FLATRELEASEDIR)\mqtile.txt NK U Then, run makeimg and download the code to target platform. Once downloaded and the OS is running, run MQDT.exe using this command at the CESH window: s mqdt client comX



28

where comX should indicate the connected com port. Note: Windbg.exe normally uses com2 for its debugging support. Therefore, MQDT.exe should use com1 instead.

1.2.2 Mobile Services (ActiveSync) Use the Mobile Services (ActiveSync) software to download MQDT.EXE from NT host to target system. The Mobile Services utility is available for free from the Windows CE 2.0 SDK. The following are abrieviated steps to enable Mobile Services (ActiveSync): 1. Connect your HPC to the NT system via Serial cable or Ethernet for Networking option. 2. Double-click on the Mobile Services icon to bring up the Communication Page. 3. Make sure the HPC device communication option (checkbox) is enabled or checked. The message: "Waiting for device to connect" should then appears. At this time, the utility will automatically initiate the communication to the device. 4. Once the connection is established, you will be prompted to login on the HPC device. Please enter your NT system login name and password for security reasons.

5. After the login, both systems will sync-up using the ActiveSync utility. You will be prompted for missing database files (if any).

6. After the ActiveSync completes the update protocols, you can use the Explorer to copy the MQDT.EXE to HPC. The easiest way is to "Drag and Drop" the executable on the Mobile Services\<HPC device name> folder. 7. Use the Run option on the HPC to invoke MQDT.EXE. For additional information regarding Mobile Services, please refer to the Help menu provided by the Microsoft Windows CE 2.0 Toolkit for Visual C++. 1.2.3 PCMCIA / Flash Card Services Copy the MQDT.EXE to the PCMCIA / Flash Card, and then use the card to Transfer and install the MQDT.EXE on your HPC devices. Please refer to your PCMCIA / Flash Card guide to install and enabled the device. 2. Build Procedure (available for OEM use only) Since the MQDT is a 32-bit program compiled using Microsoft Visual C++ 5.0, The build procedure for the source code should not be any different than any Standard MSVC 5.0 software built procedure. For this reason, the developer will provide all the necessary makefiles and .PDB files to recreate the build environment and make your MQDT builds a lot easier. The following are brief steps to rebuild the MQDT using the MSVC 5.0: 1) Install the MSVC 5.0. 2) Copy all the developer files to a designated directory. 3) Bring-up MSVC 5.0. 4) Select File and then Open Workgroup using the MQDT.DSW file (should



29

comes with the rest of developer files). If not, please contact MediaQ 5) Select Project and then Set Active Project to the target platform type. 6) Select Build and initiate Build MQDT.EXE. MSVC should create the target platform folder and placed the executable in that directory. 3. Troubleshooting This section list all known problems on MQDT along with the solutions or work-around for each and every problem. As of the release date of this Readme file, the current list of problems and solutions are as follow:

1. D9000 systems use COM1 for Mobile Services or Microsoft Debug Port, and MQDT needs to use COM2 for its Host-Client communication, but so far you cannot use the driver file from the demo to enable COM2.

4. Additional Information Contact address:

MediaQ Incorporated 2975 San Ysidro Way Santa Clara, CA 95051 (408) 733-0080 - Phone (408) 733-0085 - FAX

Documents

Windows 9X/NT & CE