1) Time/Date - March 13, 2013 2) Response time - 4 hours 3) Product - MC5590 WM6.5 4) OS Version - BSP38 5) Clarify Case # - 2791104 Partner - Agilysys, End-Customer: Weis Markets (PA area)
ISSUE: File Corruption on the MC5590, It's gotten so bad that \Application gets corrupted as well with different file sizes.
eMscript was provided and Resource.mot file was changed to copy the eMscript logs to the \Storage Card
Ive attached eMscript files for review. eMscript version used - 1.3.0
Due to the challenges I've received in getting data from the end-user (this is a grocery store worker) I'm solely relying on what the eMscript files are showing me. Hoping that somebody else can provide their feedback or agree with what I have seen and advise next steps.
My initial review of eMscript2 Resource10300521402347.csv Nothing unusual seen, it seems to be working until 3/11/2013 10:38:50 PM and then it was rebooted on 3/12/2013 5:46:08 AM
RetailMsg.txt no RTlogs generated except the RetailMsg.txt, all I see is this prior to the reboot Mudll - Unknown Radio, does this mean anything?
My initial review of eMscript3 Resource10293521401076.csv Nothing unusual seen, the device seems to be in the Contacts section of Outlook I've requested the Partner to provide details of what the failure seen here.
**************************************************8 Customer Description of the issue sent 2/26/2013: - As of today, Weis has 19 stores that are using the MC55’s with our Next Manager application (Two new stores will go live soon). - Since December they have experienced 49 device corruption failures (out of the 19 stores). - They just had 5 failures this past weekend. - Each store uses a single MC55 for this application. However each store has a backup MC55 that they keep in the safe.
They are providing this backup device specifically due to these corruption issues. Each store only has a single charger but does have two batteries. They are now considering giving each store two chargers because of this issue.
- Staging Procedures o They take an un-used MC55 and load it with Naurtech (emulation code), Next Manager Client (cab file) and our Launcher
Menu program. o They also load the Motorola Hot Fix that was given to us some time back. This fix was to help mitigate this issue. o They are also loading the EMScript tool on every device o All of the above software is loaded via MSP o They configure store specific information on the device o They then test the device to make sure everything is working properly o They exit the Next Manager program. They then exit Naurtech which brings them to our Launcher menu. o They then press the orange key which lights up and they then press the power button to suspend the device. The screen goes blank and then the orange key goes out. o Only after the orange lighted button goes out, they then remove the battery at this point and ship the device to the store. - All stores have been given the highlighted steps listed above to suspend a device before replacing the battery. - All stores have been instructed to place the device in the charger when not in use. - To date the EMScript tool has not shed any light on this issue. The EMScript log files have also been corrupted with the exception of two occasions. Support did not see anything unusual in the log files for these two occurrences. - Details of some recent failures. . . . o A store had a failure on one of these devices (corruption) so they pulled the backup device out of the safe. They placed a fully charged battery in the backup device, turned it on and it came up corrupt. This specific device was tested before it was shipped. They used the suspend procedures listed above before shipping and it still came up corrupt. o A different store stated they followed the documented battery replacement procedures but after replacing the battery the device was corrupt. o Weis did some testing in their lab. They had four devices all loaded with their software and setup to never power off or time out. They let these devices sit there until the battery ran dead. They then placed fully charged batteries in all four devices. Three of them came up find and the forth one was corrupt. **************************************************
5 Replies
Reggie,
I have looked at eMscript logs from the customer with the Mc55 file corruption.
eMscript 3 was very clean with low CPU…I see absolutely no issues.
eMscript 2 is a different story however. I see many System Time Changes when connected to an AP. I also see many roaming events. Every roam brings a time change and every time change brings very high CPU. I want to ask the customer to turn off the time sync in the Fusion options to see if that helps. Frequent system time changes have caused many issues in the past.
This is an area of concern.
John, thanks, that info review for eMscript2 and eMscript3 has been provided and advised the customer to turn off the Fusion time sync.
Can anybody provide review of the logs and see if they agree? Addtional info from the customer. 1.Date and Time when problem happened/observed B) Date and Time last known to be working.
Tuesday 3/12 about midday.
2.What was the device doing prior to failure (e.g cradled overnight with app running, battery swap, MSP provisioning etc.)
3.Was there any application running? One of the devices was being used the other would have been cradled
The one being used should have launcher running and just before the incident Naurtech, the cradled one would just have launcher running.
4. Document the steps to duplicate the issue (if possible)
I was told that the first one to fail was due to a bad battery swap. The steps could be just pulling the battery out without putting the HHU into sleep mode. The other unit was corrupt at time of need.
5.How did you recover?
I have yet to recover these units, but normally when I do I run clean boot and wipe from a SD card.
if somebody else would care to review. Please review eMscript4 (attached), we can pass on eMscript 2 and 3 as this was reviewed by ECRT. thanks. Info on the eMscript4, FYI, when they say desktop is equivalent to a start menu directory
Here is another set of logs this time from store 036. I was told that the HHU seemed to not be ringing so they rebooted the unit only to have it come up to the desktop. Yesterday midmorning. This a strange one, the root directory is corrupt but not in the normal manner. Some of the folders are no longer folders, almost like they lost the file type. Just look at the last set of logs in the end 3/13/2013
created SPR 23735