Steer your charging options

[updated 20090105, see below]
I remember that for the HTC Tornado there was a setting to disable USB charging - to allow the battery to continue discharging while connected via USB (useful or not is another topic - see further down). As long as the device is switched on, the USB and Battery drivers of the Windows Mobile operating system have control of the charging functions. When switched off, the "hardwired" functionality of the BootROM code takes over. The following only affects the options while the OS is active.

My search in the extracted modules for registry options has revealed in the usbotg.dll the elements:

• USBChargeEnable
  
• USBForceCharge
• ACCurrent
• USBCurrent
  

They are all not present by default and need to be created (only if necessary) as "DWORD" values in the registry path HKLM\Drivers\BuiltIn\UsbOtg.

As written further down, my (refurbished) device was delivered with a non BenQ charger (a Blackberry with exchangeable plugs) - so I continue to use my old HTC Tornado charger which also connects via miniUSB. The systematic (lengthy) investigation has shown the following logic for the registry variables above:

1. none present: device charges from any source (just like when switched off)
2. Charging via USB connection cannot be disabled without also disabling the HTC AC Adapter (USBForceCharge = 0 disables both), but
   
3. charging via HTC AC Adapter can be disabled, still with USB charging possible (set USBChargeEnable = 1; if you want it the other way round - it will not work, I have tried all options)
   
4. Charging via Blackberry AC Adapter can be configured independently of the USB Charging (and follows an understandable logic), I suspect the same will also apply for the normal BenQ/Kyocera AC Adapter.
   
   • ACCurrent = 0 disables the charge via the (BB) AC-Adapter
   • USBCurrent = 0 disables the charge via the USB cable of the linked PC

I have created a table with all options I tried out but It is not usefull to post it here. If you can confirm my assumptions about the BenQ Charger would be helpful.

Now the question "is it useful to discharge the battery (completely) before charging again"? After consulting many resources around the web I strongly believe "no". When busy with the batterylevel problems of the device I have collected some links - make your own decision, see here: 1, 2, 3

I know that some are keen to get hold of the Flash animated homescreen that is present in the Asian ROMs (and I suspect that most parts can be extracted from an available - yet incomplete - dump) but mind that everything that happens automatically on your device will need the CPU and battery. So I recommend reading this article at wmexperts.com.

[updated 20090105:]
After running down the battery completly, I have discovered that the charging current (get it from HKLM\System\State\Battery "ChargingCurrent" value while charging) is limited to roughly 450mA when connected via USB (also for the HTC Charger) - the USB standards allows a maximum of only 500mA anyhow. When connected to an AC Adapter (that is recognized by the system as such - e.g. my Blackberry AC Adapter) then the current draw is higher - I have seen 650mA when the battery was recovering from "emergency switch off".

The lowest voltage until which the battery is used in the E72 is very low compared to my HTC. The E72 uses the battery down to 3.356 V, while the HTC switches off already at 3.570. This may sound like big difference, but it is not in terms of capacity when you look at the discharge curve for LiIon rechargeable batteries. The battery resources I have seen on the web (see links further up) usually recommend not to use a battery below 3.6V to preserve a good lifetime.

ROM dump + extraction of files

Hi - despite you can find all what I will write below also at XDA Developers (see related links on the left side) - It took me some time to understand which program does what and which are bare necessity and which are the "nice to have" things (which I do not yet care about).
As already mentioned in my notes about the bootloader, you just need two sets of tools that will do the jobs of dumping the ROM from the device (itsutils) and then extracing (WM5editrom) all the files from the just dumped ROM image to your PC.

Dumping the ROM from the device:
This is done with the itsutils from "itsme". There is one important thing to care about when doing the dump (and it must be stressed - as other wise the dump will be incomplete). OK, so now the step-by-step action list:

1. Your device must be "application unlocked". If you do not know what that means - stop here and get a little more comfortable with what Windows Mobile is about.
2. Download the itsutils (sometimes also called XDA-Utils) from the link above.
3. Extract them to a working folder on the PC.
4. Connect your device via Active Sync if it is not linked yet - wait until sync is complete.
5. Now we need find out what file-volumes are known at the device. Get into a CMD window on your PC in the directory where you have extracted the itsutils. Enter the command "pdocread -l" (no quotes) and confirm on your device that it may run an "unknown" program. You will see a list of output similar to this:
   

   Copying F:\Share\_Smartphone\ROM + Tools\itsutils\itsutils.dll to WCE:\windows\itsutils.dll
   36.00M (0x2400000) TrueFFS
   | 2.06M (0x20fc00) Part00
   | 2.69M (0x2b0000) Part01
   | 31.25M (0x1f40000) Part02
   19.00M (0x1300000) TrueFFS
   | 2.06M (0x20fc00) Part00
   | 2.69M (0x2b0000) Part01
   | 31.25M (0x1f40000) Part02
   3.75G (0xf0300000) DSK1:
   | 3.75G (0xeff00000) (label of your memory-card)
   STRG handles:
   handle 0fb7c76a 3.75G (0xeff00000)
   handle 0fb237ee 18.98M (0x12fc000)
   handle 8fb7ca86 31.25M (0x1f40000)
   handle afb7c88a 2.69M (0x2b0000)
   handle efb7c866 2.06M (0x20fc00)
   disk 0fb7c76a
   0 partitions, 0 binary partitions
   customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   disk 0fb237ee
   2 partitions, 2 binary partitions
   customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   disk 8fb7ca86
   2 partitions, 2 binary partitions
   customerid=00000000 uniqueid= 00 00 00 00 ee 22 02 01 0a 27 03 95 07 06 05 a0
   disk afb7c88a
   2 partitions, 2 binary partitions
   customerid=00000000 uniqueid= 00 00 00 00 ee 22 02 01 0a 27 03 95 07 06 05 a0
   disk efb7c866
   2 partitions, 2 binary partitions
   customerid=00000000 uniqueid= 00 00 00 00 ee 22 02 01 0a 27 03 95 07 06 05 a0
   

   I have issued the command above for my Tornado device - not the E72 (which is in a "lets see how long it survives in standby without charging" test), so it will look different, but the important thing to notice is the length of the part02 partition (marked in bold red) above. You need this for the command to actually dump the ROM in the next step.
6. Now enter "pdocread 0 (your-value-here-no brackets) part02.dump" like I did here:
   

   pdocread 0 0x1f40000 part02.dump
   CopyTFFSToFile(0x0, 0x1f40000, part02.dump)

   You see above that it starts to copy date from the device to the file. This takes several minutes - you can watch the file grow in the Windows Explorer if you like to - so be patient until you see the prompt again.
   That's it for extacting the ROM - nothing more to do if you just want to share it with others. Put "part02.dump" in a ZIP/RAR and label it with what you know about your device (Kyocera or BenQ - Windows Mobile Version - ROM Version from "Settings - About: Image Version, Build Date, Build Time).
7. If you want to dig deeper a little you may want to extract the contents of the just dumped ROM image. For this you need the WM5EditRom tools (imgfs_tools). Extract them in a different folder (e.g. aside the itsutils) and move the part02.dump file there as well.
8. Now enter again a CMD window - this time in the folder where you have extracted the imgfs_tools and moved the part02.dump. There enter "prepare_imgfs part02.dump -nosplit" resulting in:
   

   Searching for IMGFS start... Found at 004C0000
   Dumping IMGFS ...
   Done!

   This has created two files: imgfs_raw_data.bin and imgfs_removed_data.bin which is empty. The first is now the complete ROM filesystem and needs to be further decomposed with the next command.
   Again mind that the examples above are not originating from an E72/E4000 (WM6) but from an HTC Tornado (WM5), so your filesizes and addresses will be drastically different.
9. So now the last command for decomposition: Enter "viewimgfs imgfs_raw_data.bin > viewimgfs-output.txt" (no qoutes) on the commandline and press enter. As the command output is redirected into a file (using > filename) you will see nothing - but after a minute or so the command prompt returns. You can now examine the file "viewimgfs-output.txt" for errors (there should be none).
   The command has created a new directory below the current - called DUMP. Within this directory you find all files and modules that have been part of the ROM filesystem. You will notice that some files are just there like in the \windows directory of your device and others are decomposed in own directories. I am not expert enought to tell details here - consult the various discussions abuot ROM cooking at XDA Developers.
   Mind that often the reconstructed *.dll or *.exe in the module directories cannot directly replace their ROM counterparts.
10. The toolset contains also powerful tools to reassemble an imgfs and reconstruct an item to dump back to ROM. For me there are still too many things I don't understand - so I stop here describing anything more. Look up yourself at the referenced sources.
    

Still several questions stay which require to dive deeper in the water of understanding how the ROM filesystems on WinCe work before I recommend anyone to dare writing anything back to the device. Things I need to understand include:

• What do the other partitions of the filesystem contain?
• How are the partitions of the filesystem depending on each other?
  
• What is in the part of the ROM dump before the actual imgfs?
  Here I suspect the boot-image and the Radio ROM - but this needs to be confirmed still.
  
• Can the imgfs be cut down to use only the size of the actual (compressed) content?
  In my case the dumped ROM contains only FF starting from address 0x3569250 until the end at 0x4d0bfff - this makes roughly 24 MB of wasted space that was surely intended to hold other ROM options like localizations and programs. Would be good to get that as normal device installation memory.
  

Bootloader - how (unsolved yet)

Beeing used to the community with my HTC devices - it seems that we are at loss currently to have low-level access without the operating system running. The only thing that runs well are the itsutil tools from XDA devloper "itsme" - look there: http://wiki.xda-developers.com/index.php?pagename=XdaUtils
Also other tools that operate on the extracted filesystem images (e.g."ROM Kitchen" or also WM5editrom) are working as expected - yet I did not dare yet to flash back anything via pdocwrite :-)

Some low-level acess should be possible, however I do not yet know how. What I found out so far is:

• Pressing power-on and holding the message-key will send a USB signal to a connected PC. The Windows-XP PC then searches for a "Neptune" USB device - for which the web hardly offers anything useful, except:
• The Motorola Flash tools (yes another deja vu with Motorola) require dedicated drivers to install. After this is done succesfully - well nothing more happens.

It seems that in the very short time (3 seconds) that this temporary state of USB exists some communication has to be established to keep it alive. Any hints are welcome.

I have also hoped that tools available for the BenQ P51 may help here, but it just seems that they are not doing more than itsutils can do already. And since we do not know yet addresses of the various parts of the ROM, nothing gained here either :-(

Remove UMAClient.exe

You can remove UMAClient.exe from \HKLM\init\Launch.. but still keep WiFi switched off after reboot. UMAClient cares for the settings in Settings->Connections->WiFi transmission. If not loaded also the WiFi mode to disable WiFi if not connected after does not work after startup.
This can be solved by a little program which toggles the WIFI settings, put it either in the startup folder or at the place in the registry where UMAclient.exe was present.

I found the origin of the file I copied from the web - and that works ok. It was posted at XDA-developers here: http://forum.xda-developers.com/showpost.php?p=1773191&postcount=1 it even has a cab to install it. It also reveals the author "smartmadsoft". BTW: their program SamsungBacklight does now also work for the E72 - you have to edit all *.lnk files and add the parameter "-benq" (including a leading blank and the quotes) to them. Mind that the SamsungLamp does not work, but for that purpose another great free utility exists "MultiFlashLight" by Igor V. Bozhko (2006).

Interesting Programs in \windows

Interesting Programs (not linked via .lnk files) in \windows:

• DevHealth.exe will also be called by LogMaster and creates a very elaborate memory and process report. It is named "mem_1.txt" and is either located in the Storage Card root or the main memory root, sized ~ 292kB. Subsequent calls will generate files named mem_.txt where relates to the called number. This file includes the DLL relationship of all active loaded modules, so it is easy for ROM cleaners to sort out the debug ROM remains.
  -> This is the key application to investigate further any modifications of Startup options or ROM modifications.
• LogMaster.exe sets various trace and log points, can call netlogctl.exe, swmodemtrace.exe, celogflush.exe, DevHealth.exe, WinsockLogApp.exe, links to LogUtil.dll which relates to logfiles: OSImageVersion.txt, sqpco.log, sqmodem.log, sqdriver.log, sqatcmd.log
  My version is 2.4 (I have seen already 2.5 in another ROM).
  
• QDW.exe (internall referenced: "QDW.exe is launched by AppExceptionMonitor.exe", but this .exe is missing, only a dll is remaining) This would read (or write) to files in \Windows\System\ExceptionExtraLogs\. It calls copylog.exe to do the job.
  If directly called it asks for a memory card and generates a directory \yyyymmdd_hhmmss\ExceptionExtraLogs\ generating (copying) files ELog.txt KITL.txt qatcmd.log qdriver.log qmodem.log qpco.log verinfo.txt call is finished with "copy failed".
• PreForWSA.exe is called via HLKM\init\Launch.. and may prepare WinSockLogging (may call \Windows\WinsockLogApp.exe)
• prtscrn.exe generates a screendump of the current state, it is also called via long press of the Vol-Up key and generates a file called scncap.jpg in the "\My Documents" folder ( is a sequence number starting at 1).

Retrieve hidden settings/options

Retrieve hidden settings/options in the setup menus by removing the commenting in the relevant XML files:

• callforwarding.cpl.xml get CFU settings for Data and Fax (Phone->Call Forwarding)
• clckalrm.cpl.xml get Automatic Timezone setting from Network (Clock&Alarm->TimeZone->AutoTimeZone)
• telephonygsm.cpl.xml get Frequencyband selection (Phone->Band Selection = usually "automatic")
• connectgsm.cpl.xml get SMS delivery options (Connections->SMS Service = usually "circuit only")

You will need to copy these files to your PC from the device's \windows directory, edit it with a Unicode capable editor (notepad.exe) and copy them back to the device's \windows directory. A reboot is not required. Changes persist until you have to do factory-reset (so hopefully forever).

Install more than one T9 language

• get packages from http://melgurth.ovh.org/index.php?page=downloads
• download also the package that you already have + the ones you want (so all have the same version) - if you miss to download ALL packages it will spoil your T9 completely
  
• install them all, ignore device reboot requests in the meantime
• edit HKEY_LOCAL_MACHINE\T9 Input Method\MUI\Languages string "Available" to contain concatenated (separated by comma) all language numbers
• reboot device

Cleaning up the \windows directory

Despite the device has much more free memory (around 25 MB) to install programs on the device than my old Tornado (around 10 MB), I still want to have the device cleaned up from things I do not need. As I (still) have a BT-Fusion branded device, some tips may not be applicable for yours.

• Remove locales not needed for MunduIM (fr, it, br, ...directories)
• \Data folder is for beetzRSS -> move to SD card in options menu
• \Java folder for JBED -> move to SD card, change keys in registry at (HKEY_CURRENT_USER\Software\JBlend)
• \Profiles folder for PIE -> move to SD card by changing paths at: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders (may not be persistent if card is not ready at boot time or is removed)
• \Rings folder for ringtones -> also in \windows but are not referenced from there, so they stay here
• \skins folder is for HipCam (HKEY_LOCAL_MACHINE\Software\Emuzed Inc\HipCam)
• \sounds folder is for Camera sounds (HKEY_LOCAL_MACHINE\System\Pictures\Camera\OEM)
• \themes folder is for HipCam (HKEY_LOCAL_MACHINE\Software\Emuzed Inc\HipCam)
• \traveller folder for FIZZ Traveler (move to SDCard, change items in HKEY_CURRENT_USER\Software\FizzSoftware\MicroClient\TRS)

General tip: When the device is first booted (or after a factory reset - pushing left+right softkey when turning on) several actions are taken to copy files from the \windows directory (as a repository) to various place on the device. Some things a necessary for the functions to work right, some are not.

Hacking the USB Headset connector

[Updated 20090105 - see below]
Well - much to my disappointment, my device (claimed as - nearly new, factory refurbished) was delivered with a set of non-original parts. I received a Blackberry charger which has the option to exchange the plug for the mains-socket, so it also works in my continental sockets in Germany - no problem here, especially as all my other chargers (from my older HTC devices) also work.

BUT: the delivered headset was a cheap Motorola S200 replacement - which has the same plug, but different connectors inside. No way to get it working :-(
I knew that I will not use the original headset, but I need a blueprint to understand what is going on to build an USB-3.5mm adaptor. As I do not have that (yet - hopefully), I have checked other options to debug the duplicate purpose of the standard mini-USB (5 pin) plug.

The good part is that you have big variety of Motorola Headsets or adaptors that you can start working with - just look for the Razor-V3, it has the same physical connector.
The bad part is that the multiple use of the same socket for different purposes creates the need to have the device switch between these modes. Also here it is advised to have a look at related Motorola resources, e.g. here: http://wiki.openezx.org/EMU
Unfortunately the described options do NOT work for the E72 - but they give a clue on what to investigate...

Terminology:
The USB socket has 5 pins + shield, sometimes the numbering is 1,2,3,x,4, but I prefer to number the pins in sequence, i.e. 1,2,3,4,5 - just like the EMU wiki above does.

Findings:

1. Connecting a resistor in the range of 50 to 200 kB between (5+Shield) and (1) will raise the level at (1) from 0,3V to the full power of the battery (you can drive a light with this!) for exactly 10 seconds.
   
2. Pin (3) (the middle one) will generate a stepping voltage output (1 Hz) as long as (1) is up - here I suspect an action is required to confirm the operation mode.
3. nothing more - I had to give up here...

Conclusion:

• The temporary presence of (a fully powered) supply voltage at pin (1) and the activity at pin (3) may indicate an active wired headset (just like the Motorola). It is however impossible to tell without a real E72 headset at hand...

[Updated 20090105:]
Thanks to the community in Taiwan, see this post, the connection strategy is now settled :-)
Continuing my discussion above the "protocol" on pin(3) is very simple - just connect a resistor (below about 250 ohm) to grounds - that's all - the device will go into headset mode (can also be seen at HKLM\System\State\Hardware - the value of the "Headset" property changes to "1".
After the device is in headset mode, pin(3) can be released again (what I did to identify the other speaker channel and microphone connection). So the final result is then for the numbered pins of the USB connector (1-5):

1. Must be connected with a resistor less than 200 kOhms (but more than 10k - not to drain the battery) to ground. The voltage will rise briefly to battery level (so if you short cut this to ground it may kill it) but then drop back to 0,16 V to stay there. I suspect that accepting calls with the headset button will introduce new functionality here...
   
2. Speaker channel (l,r not checked, source indicates right here) - must be connected to a speaker or a pulldown resistor at device-headset connection time.
   
3. Speaker channel (l,r not checked, source indicates left here)
4. Microphone channel (checked to work with Audionotes)
   
5. Grounds

So luckily no complicated electronics - get your soldering irons ready!

Mind that the drawing in the Taiwanese post labels the "V+" and "GND" incorrect - they have to be reversed. The "NC" (microphone) pin is close to the - (GND) pin.