Someone's blog about Hopper .. gud one

Hopper: Start Menu Dead!

Some of you may be testing with Hopper now for certification and/or being asked to meet Mean Time To Failure (MTTF) bars as part of a relationship with a device maker. In order to be labeled a Windows Mobile powered device, the unit must pass a series of tests which are collectively known as the LTK (Logo Test Kit). If you ship your software in-ROM then your app becomes part of the stability tests they have to pass before release. There is nothing worse then to be sitting on a huge opportunity to ship in-ROM and find yourself as the focus of a failed Hopper test and holding up the device release.

Hopper isn't very smart, but he's surprisingly effective at exposing MTTF issues. Lately, I've had several partner become the subject of "Start Menu Dead" failures so I thought it might make a useful post.

For those of you unfamiliar with Hopper, it's a simple little app that basically simulates a 5 year old, jacked up on sugar that has taken over your mobile device. Tapping like crazy-- switching apps-- doing all kinds of things that a normal user might never do. Maybe that's not a completely fair description-- but think of a lot of random events that are periodically paused to make sure basic system functionality is still responsive-- like the START MENU.

Hopper runs for a period of time and reports a number of failure scenarios. Examples:

• Default system crash; this is where Hopper is not able to send keystrokes and mouse events.
• Start menu not responding. this is where Hopper is able to send keystrokes and mouse events but is not able to switch to any other application.
• Stuck in the same window, this is where Hopper is able to send keystrokes and mouse events but it detects that it is stuck in the same window for more than 15 minutes. Once this happens Hopper will attempt to dismiss the current foreground window by sending ENTER keys, sending simulated screen taps around the 4 corners and the center of the window, sending ESCAPE keys, try to find a button to click, and finally it will also try to switch away by clicking the Start menu. If none of the above attempts change the foreground window, it will quit and report a hang.

Applications that run in full screen (using SHFullScreen) can sometimes create problems for Hopper. Since Hopper likes to jump around, switch apps, and test the Start Menu-- it needs to be able to get out of an application running in full screen mode. Many full screen apps like games, navigation software, etc., will use a custom UI to take over the display and omit standard exit controls and window messages that Hopper uses. Once Hopper gets into a full screen app like this, it can get stuck and then report failures when it can't get out or access the Start Menu. When it does, your failure log will often look something like this:

Build = 15342 (OS 318)(Hop 2.0.15.7472).

Random Seed = 55592.

Previous runtime = 21 mins (0 hrs 21 mins).

Ended by: Start menu dead, not responding!

Boot count (prev): 3 (0)

ACTIONS/min = 149

Total States = 10

…

ACTIONS/min = 149; Total States = 10

FREE MEMORY: 75620 KB

FREE DISK: 25894 KB

EndType = Start menu dead, not responding

The important stuff
If you have an application that runs in fulls screen mode, be sure that Hopper can get out and access the Start Menu. If it sends a VK_THOME,it should always take you to the Home Screen. If it sends a VK_LWIN then it should always bring up the Start Menu. If you do anything to hold focus or prevent those mess ages from activating another window, then you will have problems. If Hopper cannot get out, it will try to dismiss your application by issuing a VK_ESCAPE and VK_RETURN on PPC (Classic/Pro). On Standard (Smartphone) it will attempt to dismiss by trying variations of the softkeys and sending a VK_TBACK. Make sure you handle those messages to close your app or release screen control in order to avoid the Start Menu Dead failure in Hopper.

Be sure to check out the Hopper blog for more info on using this tool.

port Nuc to Davinci EVM DM6446

steps to port Nuc
1) RBL loads the UBL. RBL can load UBL of size upto 14KB in DM6446.
2) So i need to write my own UBL or get the source code of UBL and modify it as per my requirement. if i cannot get UBL source code from TI's site ..i can have u-boot which i think is open and is available in linux sites.
3) after that i have to change the kernel code ...int.s , tct.s,tmt.s

Windows CE Build process

Windows CE build process

When I started working with win CE drivers, i had no time to understand the WinCE build process. All I did was, follow some build procedures and get my driver up and running without knowing much the build process. I think its time to investigate it.

In Platform Builder, when you choose to build a run-time image based on an operating system (OS) design, the build system executes four sequential phases:

Each phase also executes a secondary phase defined as the Localize phase, when resources and executables are translated into selected locales. For more information about localization, see OS Localization.

1) The Compile Phase: - Turns C code into libraries.

During the Compile phase, the compiler (Build.exe) and the linker use source code files to generate static libraries. These libraries are linked during the Sysgen phase to create executable files.

Microsoft runs a tool named cebuild to do this. It will first run 'build' on \private\winceos, and then on public\winceos, then it will run sysgen (see step 2). Information about cebuild can be found in (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcepb40/html/_wcepb_windows_ce_build_environment_tool.asp)

Localization tasks performed during this phase include compiling resource script (.rc) files to create binary resource (.res) files, which are translated based on the selected locales.

2) SYSGEN PHASE: Turns libraries into DLL's, based on which libraries are required for componentization.

During the OS design generation, or Sysgen phase, the build system sets or clears Sysgen variables.

The inclusion of Sysgen variables is typically based on the selection of Catalog items that you include in your OS design. The relationship between Sysgen variables and Catalog items can vary. A Catalog item might correspond to more than one Sysgen variable.

The build system determines which variables to set or clear by processing the Cesysgen.bat files associated with the OS design, which are in %_WINCEROOT%\PBWorkspaces\<OS Design name>\Oak\Misc.

The master Cesysgen.bat file manages a set of subordinate batch files that correspond to the dependency trees included in the OS design. The build system uses these variables to link the corresponding static libraries into modules.

The build system also filters the header files, creating headers that only contain prototypes for the functions exported by your OS design. Import libraries for the modules are also created during this phase.

The filtered header files and import libraries are included in the software development kit (SDK), which others can use to create applications that run on the new OS.

Also, OS design configuration files are filtered to create a new set of configuration files specific to your OS design, which are used in the Make Image phase.

At the end of the Sysgen phase, the board support package (BSP) is built.

Localization tasks performed during the Sysgen phase include selection of input method editors (IMEs) and fonts for Asian languages, based on the selected locales.

Environment variables and actions are executed on a per project basis, which means that environment variables you set in one project do not affect variables defined by another project.

In all other build phases, variables are defined globally.

You can set global environment variables on the Environment page in the Property Pages dialog box. For more information, see OS Design Property Pages: Environment and Setting or Clearing an Environment Variable (Visual Studio).

For information about setting project-specific environment variables, see Subprojects: General Settings.

3) The Release Copy Phase or BUILDREL: Copy all the DLL's from stage 2 into a central location.

During the Release Copy phase, the build system copies all files that you need to make a run-time image to the release directory. The modules and files created during the Sysgen phase are copied to this directory first, followed by the files created in the Compile phase.

Note: During the Release Copy phase, binary image builder (.bib) and registry (.reg) files are propagated to the Release directory. However, if your headers and libraries are up-to-date, this phase might not be executed. If you make changes in these files, verify that Copy Files to Release Directory After Build and Make Run-Time Image After Build are selected; then from the Build menu in Platform Builder, run Build and Sysgen to ensure propagation of the changed files.

4) The Make Run-Time Image Phase or MAKEIMG: Munge all the DLL's, registry settings, etc... into a ROM image.

During the Make Run-Time Image phase, the files in the release directory are combined to create a run-time image, typically named Nk.bin.

At the beginning of the phase, the project-specific files, which include Project.bib, Project.dat, Project.db, and Project.reg, are copied to the release directory.

Localization tasks performed during this phase include the attachment of resources to executables and string substitutions for configuration files, based on the selected locales. For more information, see Make Binary Image Tool.

This phase corresponds to the Make Run-Time Image command on the Build menu.

If you modify the project-specific files, or otherwise modify files in the Release directory, you must run the Make Run-Time Image command before the changes are reflected in your run-time image. For more information, see Building a Run-Time Image.

After the run-time image is created, you can download it to a target device. For more information, see Downloading a Run-Time Image.

For information about creating and building a run-time image using the IDE, see How to Use the IDE to Create, Customize, and Build a Run-Time Image.