7. Add a new header file called DbgZone.h to the subproject and define the following zones:
#include <DBGAPI.H>
#define DEBUGMASK(n) (0x00000001<<n)
#define MASK_INIT DEBUGMASK(0)
#define MASK_DEINIT DEBUGMASK(1)
#define MASK_ON DEBUGMASK(2)
#define MASK_ZONE3 DEBUGMASK(3)
#define MASK_ZONE4 DEBUGMASK(4)
#define MASK_ZONE5 DEBUGMASK(5)
#define MASK_ZONE6 DEBUGMASK(6)
#define MASK_ZONE7 DEBUGMASK(7)
#define MASK_ZONE8 DEBUGMASK(8)
#define MASK_ZONE9 DEBUGMASK(9)
#define MASK_ZONE10 DEBUGMASK(10)
#define MASK_ZONE11 DEBUGMASK(11)
#define MASK_ZONE12 DEBUGMASK(12)
#define MASK_FAILURE DEBUGMASK(13)
#define MASK_WARNING DEBUGMASK(14)
#define MASK_ERROR DEBUGMASK(15)
#define ZONE_INIT DEBUGZONE(0)
#define ZONE_DEINIT DEBUGZONE(1)
#define ZONE_ON DEBUGZONE(2)
#define ZONE_3 DEBUGZONE(3)
#define ZONE_4 DEBUGZONE(4)
#define ZONE_5 DEBUGZONE(5)
#define ZONE_6 DEBUGZONE(6)
#define ZONE_7 DEBUGZONE(7)
#define ZONE_8 DEBUGZONE(8)
#define ZONE_9 DEBUGZONE(9)
#define ZONE_10 DEBUGZONE(10)
#define ZONE_11 DEBUGZONE(11)
#define ZONE_12 DEBUGZONE(12)
#define ZONE_FAILURE DEBUGZONE(13)
#define ZONE_WARNING DEBUGZONE(14)
#define ZONE_ERROR DEBUGZONE(15)
8. Add an include statement for the DbgZone.h header file to the TestDbgZones.c file:
#include "DbgZone.h"
9. Define the dpCurSettings variable for the debug zones above the _tmain function, as follows:
DBGPARAM dpCurSettings = {
TEXT("TestDbgZone"), {
TEXT("Init"), TEXT("Deinit"), TEXT("On"), TEXT("n/a"),
TEXT("n/a"), TEXT("n/a"), TEXT("n/a"), TEXT("n/a"),
TEXT("n/a"), TEXT("n/a"), TEXT("n/a"), TEXT("n/a"),
TEXT("n/a"), TEXT("Failure"), TEXT("Warning"), TEXT("Error")
},
MASK_INIT | MASK_ON | MASK_ERROR
};
10. Register the debug zones of the module in the first line of the _tmain function:
DEBUGREGISTER(NULL);
11. Use the RETAILMSG and DEBUGMSG macros to display debug messages and associate them with debug zones, as follows:
DEBUGMSG(ZONE_INIT,
(TEXT("Message : ZONE_INIT")));
RETAILMSG(ZONE_FAILURE || ZONE_WARNING,
(TEXT("Message : ZONE_FAILURE || ZONE_WARNING")));
DEBUGMSG(ZONE_DEINIT && ZONE_ON,
(TEXT("Message : ZONE_DEINIT && ZONE_ON")));
12. Build the application, attach to the target device, and then start the application by using the Target Control window.
13. Note that only the first debug message is displayed in the debug Output window:
4294890680 PID:3c50002 TID:3c60002 Message : ZONE_INIT
14. Open the registry editor (Regedit.exe) on your development computer to activate the remaining debug zones, by default.
15. Open the HKEY_CURRENT_USER\Pegasus\Zones key and create a REG_DWORD value called TestDbgZone (according to the name of the module defined in the dpCurSettings variable).
16. Set the value to 0xFFFF to enable all 16 named zones, which correspond to the lower 16 bits in this 32 bit DWORD value (see Figure 4-15).
17. In Visual Studio, start the application again, and notice the following output:
4294911331 PID:2270006 TID:2280006 Message : ZONE_INIT
4294911336 PID:2270006 TID:2280006 Message : ZONE_FAILURE || ZONE_WARNING
4294911336 PID:2270006 TID:2280006 Message : ZONE_DEINIT && ZONE_ON
18. Change the TestDbgZone value in the registry to enable and disable different debug zones and verify the results in the Output window of Visual Studio.
Figure 4-15 HKEY_CURRENT_USER\Pegasus\Zones: "TestDbgZone"=dword:FFFF
You cannot control the debug zones for the TestDbgZone module in Platform Builder because the application process exits before you can open and modify the active zone for this module. You can only manage debug zones for loaded modules in Platform Builder, such as for graphical applications and DLLs.
► Perform Mouse Driver Tests by Using the CETK
1. Open the Windows CE Test Kit application from the Start menu on your development computer (open the Windows Embedded CE 6.0 menu and click Windows Embedded CE Test Kit).
2. In the Windows Embedded CE Test Kit window, open the Connection menu and click Start Client to establish a connection to the target device.
3. Click Connect and select the device in the Connection Manager window.
4. Verify that the workstation server application connects successfully to the device, deploys the required CETK binaries, detects available device drivers, and displays a list of all components in a hierarchical tree, as shown in Figure 4-16.
5. Right-click the Windows CE Test Catalog node and click Deselect All Tests.
6. Open each node in the list and select the Mouse Test check box.
7. Open the Test menu and then clock on Start/Stop Test to perform a mouse test.
8. On the target device perform the required mouse actions.
9. Complete the test and then can access the test report by right-clicking the test entry and selecting View Results.
10. Examine the results in the CETK parser and notice successful, skipped, and failed test procedures.
Figure 4-16 Device categories in the Windows Embedded CE Test Kit window
Chapter Review
Platform Builder for Windows Embedded CE ships with a comprehensive set of debugging and testing tools to diagnose and eliminate root causes of errors, and validate the system in its final configuration prior to its release to production. The debugging tools integrate with Visual Studio and communicate over KITL connections with the target device. Alternatively, you can create a memory dump and use the CE Dump File Reader to debug the system in offline mode, which is particularly useful for postmortem debugging. The debugging environment is also extensible by means of eXDI drivers to perform hardware-assisted debugging beyond the capabilities of the standard Kernel Debugger.
The Kernel Debugger is a hybrid debugger for kernel components and applications. Debugging starts automatically if you attach to a target device with KdStub and KITL enabled. You can use the Target Control window to start applications for debugging and perform advanced system tests based on CEDebugX commands. However, it is important to keep in mind that you cannot set breakpoints in interrupt handlers or OAL modules because at these levels, the kernel operates in single-thread mode and stops communicating with the development workstation if code execution halts. To debug interrupt handlers, use a hardware debugger or debug messages. The debug messages feature supports debug zones to control the information output without having the rebuild the run-time image. You can also use debug messages to debug the C-code portion of a boot loader, yet for the assembly code portion you must use a hardware debugger or an LED panel.