| Author |
Topic |
|
|
Susan
123 Posts |
 Posted - 30 Sep 2005 : 08:12:06
|
On some of our BitsyX boards, after calling TouchScreen() programmatically, our application terminates with either
0xC000001D – Undefined Instruction, or
0xC0000005 – Data Abort
shortly after the user attempts to continue with the program. If calibration is by-passed, no error.
This is not occurring on all of the boards. We have some BitsyX boards which do not have this problem.
The software being loaded onto the boards is identical from device to device – same HWT, REG, ROM, ADSLOAD.EXE, NK.BIN, application.
On the systems which have this problem, I have even had to entirely reload the image, because the device would not even complete booting on the next power cycle. Things have gotten to this state after the user initiates a calibration (TouchScreen() is programmatically called), then the user initiates another function which attempts to write to the FlashFx disk. After about 45 seconds, a standard message box – something like File Not Found – may appear.
Or the device may just lock up, with no messages out the serial port. Upon reboot, ‘Formatting Flash Disk!!! Formatting Done!!!’ messages through the serial port, which then erases data which we have stored there, causing an inoperable device.
We have consistent aborts on certain boards, but the aborts are being manifested differently.
Compiling the application in Debug mode, and running through Active Sync is not helping, as the application does not terminate in debug mode. No surprise.
Of course, any attempts at creating a small program demonstrating this problem have not been successful (or they have been successful, depending upon you viewpoint).
4.10.36, 1.10, and 4.20.17, 1.14 have both been tested with the same results.
Next????
Update: after calling TouchScreen() programatically, sending a RETAILMSG out through the serial port that the function successfully completed, and exiting the application, the device would not boot, forcing me to reinstall the image.
And HWT, and REG...just reinstalled everything...
Here's some more information...
After calling TouchScreen(), and exiting the application, the device would not boot. The screen displays some of the Calibration program text, but it is garbled - large font, overwrites itself, large crosshairs.
Furthermore, the serial port output displays the message
"Initializing ADSLoad.reg Parsing driver...failed."
I didn't notice that right away, so I reinstalled only HWT because of the garbled display. As soon as I noticed that message, I dumped ADSLoad.reg onto the PCMCIA card, and the device now boots.
Now I calibrate the screen, exit the application, reboot the device, and I'm back to 'Parsing driver...failed'.
I can do this for hours.
In addition to the 'Parsing driver...failed.' message, I also get
Could not open File \Temp\adsload.reg.
Could not open File \Temp\adsload.reg.
(Yes, I get this message twice in succession.)
The last serial port data is...
Microsoft Windows CE Ver. 4.20 (build 0)
BitsyX Windows CE Ver. 4.20.17 BITSYX_CORE_RAM |
Edited by - Susan on 30 Sep 2005 13:27:44 |
|
|
akidder
1519 Posts |
Posted - 30 Sep 2005 : 15:50:23
|
The most likely source of the problems is two or more threads accesssing the flash disk simultaneously. The touch panel driver saves calibration data to flash independently from the flash disk driver. Do I recall correctly that your application also writes directly to flash in some cases? Any two of these at the same time can create a situation where random blocks of flash can get wiped out (e.g. the messed up display suggests that your display timings in adsload.hwt and/or .reg got erased).
Your best bet is to make sure that when you are performing a tp calibration, there is no chance that anything else is going to write to flash.
The newest BitsyX releases use both the hive-based registry and a more robust flash file driver to significantly reduce the chance of flash file corruption. There is a small additional license cost for the upgrade.
If there's nothing obvious that's accessing flash, I'd be glad to do some more brainstorming on the phone to get to the bottom of this. |
 |
|
|
Susan
123 Posts |
Posted - 30 Sep 2005 : 15:57:03
|
What? Are you reading my mind?
I just put in a delay (using WaitForSingleObject) after TouchCalibrate() has completed, in order to give the thread writing to ADSLoad.reg sufficient time to exit.
And no more problems... (I hope)....
Just didn't have enough time update this topic. |
|
|
|
Susan
123 Posts |
Posted - 03 Oct 2005 : 10:24:09
|
Sorry for the brevity of the reply on Friday.
To clarify our applications...we abandoned the idea of updating the flash directly some time ago, due to the potential for having horribly corrupt files, and an unbootable device in our client's hands. So it wasn't the case that the application was conflicting with the TouchCalibrate() program by also writing directly to flash.
The interesting point of all this was that I was putting in what I belileved to be a 'brute force' fix - after the user calibrates, exit the program, since having these data abort/undefined instruction boxes on the screen was unacceptable. It wasn't until I did that, that the problem just blew all out of proportion. I now consistently had a corrupt ADSLoad.reg after every calibration. The good part of all this was that the 'brute force' approach helped to point me to the underlying problem - that being that the thread doing the ADSLoad.reg write was apparently still running even after the TouchCalibrate() function completed successfully. Calling exit() IMMEDIATELY after TouchCalibrate() returned was not a good idea at all. But again, it helped me determine a solution with which I was much more comfortable.
So now I'm in the middle of revamping code, providing our clients with warnings about not cycling power until the device displays a message that calibration is complete. And this message is not displayed until we return from the WaitForSingleObject(). And so far, so good.
|
|
|
| |
Topic |
|
|
|
All Forums
Microsoft Windows CE
Aborts after Calibration
Forum Locked
Send Topic to a Friend
Printer Friendly