AR1100 calibration software bug

[hoosieree]

Hi all,

I just discovered that using the AR1100 calibration software in a NORMAL manner will result in a partially* bricked device. Here is what NOT to do:

0. connect AR1100 USB adapter
1. start calibration software
2. choose Communications Mode -> Digitizer
3. click Verify Communication

While it will continue to work as a digitizer, it is now no longer possible to run the configuration utility or change modes.

From this point on, the device will enumerate as "Digitizer", regardless of what setting is selected.

Note that the Adafruit documentation states:

This is kind of the fix-all button if you ever find you got the AR1100 in a weird mode.

But unfortunately this is not true.

If anyone has tips on how to get the AR1100 working again (meaning "able to communicate with the configuration utility"), please let me know.

This was done on a recent x86-64 machine running Windows 8.1

Here's the log output:

Code: Select all

3:05:11 PM  Welcome to the Microchip AR Configuration Utility version 2.20

3:05:11 PM  Wizard opened . . .




3:05:13 PM  Wizard set dev kit type to custom

3:05:15 PM  Wizard set number of touch sensor wires to 4

3:05:17 PM  Wizard set device type to 1100

3:05:19 PM  Wizard set protocol to USB Mouse

3:05:21 PM  Wizard set protocol to USB Mouse

3:05:21 PM  Wizard set protocol to USB Digitizer

3:05:24 PM  Found Tub.dll - Ver: 1.5.0.0

3:05:24 PM  Error: Could not change mode to Digitizer.  Verify the AR1100 is properly attached

3:05:28 PM  Wizard set protocol to USB Digitizer

3:05:29 PM  Wizard set protocol to USB Mouse

3:05:31 PM  Found Tub.dll - Ver: 1.5.0.0

3:05:31 PM  Error: Could not change mode to Mouse.  Verify the AR1100 is properly attached

3:05:35 PM  Found Tub.dll - Ver: 1.5.0.0

3:05:35 PM  Error: Could not change mode to Mouse.  Verify the AR1100 is properly attached

3:05:36 PM  Wizard set protocol to USB Mouse

3:05:41 PM  Wizard aborted . . .

3:05:41 PM  Wizard aborted before communications established.  Open the Options window from the Tools section of the ribbon to set communications mode.

3:05:50 PM  Found Tub.dll - Ver: 1.5.0.0

3:05:50 PM  Error: Could not change mode to Mouse.  Verify the AR1100 is properly attached

3:06:01 PM  Found Tub.dll - Ver: 1.5.0.0

3:06:01 PM  Error: Could not change mode to HID.  Verify the AR1100 is properly attached

3:06:06 PM  USB AR1100 Digitizer Removed . . 

3:06:27 PM  USB AR1100 Digitizer Detected . . 

3:06:30 PM  Found Tub.dll - Ver: 1.5.0.0

3:06:30 PM  USB AR1100 could not be found.

Please check your connections.

[adafruit_support_mike]

Did you toggle Expert mode as described on this page?

https://learn.adafruit.com/ar1100-resis ... guide/help

[hoosieree]

Yes.

[adafruit_support_mike]

The wizard is complaining about USB errors, so let's check basic hardware recognition.

Does the AR1100 enumerate as a device with a COM port and USB vendor ID?

[hoosieree]

Under Devices and Printers, it shows as AR1100 HID-DIGITIZER. No COM ports because it's enumerating as a USB device. Vendor is Microsoft.

Again, it is working as a digitizer, meaning I can click buttons and swipe-to-scroll, drag things around, etc. But for whatever reason the Microchip calibration tool won't program it anymore.

[adafruit_support_mike]

Try downloading the AR1100 Configuration Utility and its documentation from Microchip:

http://ww1.microchip.com/downloads/en/D ... yV2.20.zip
http://ww1.microchip.com/downloads/en/D ... 41605B.pdf

That has more options than the calibration tool, including one that should reset the chip to its default configuration.

[hoosieree]

My mistake, I was indeed using the AR Configuration Utility (not the AR Calibration stuff).

[adafruit_support_mike]

Send a note to [email protected] with a link to this thread and the folks there will get you a replacement.

[hoosieree]

Hey, wanted to give an update on this. I downgraded to Windows 7 and suddenly both the calibration and configuration software Just Worked (TM). The fact that Microchip's driver requires .NET 2.0 should have been a clue, but there you have it.

Hope this helps someone, Cheers!

[adam_w]

Hi all,

I came across this thread the other day after winding up in the exact same situation and thought I would post the outcome of my findings and resolution to the issue in case it helps the next person this will inevitably happen to.

So I recently bought a Rasberry Pi 2 with the intention of installing Windows 10 IoT core and playing with some universal app development and the Adafruit 2260 with touchscreen seemed like a good match for my needs. This display comes with the AR1100 as a backpack module.

After setting up the Pi and having a play I was curious to see if it would work in digitizer mode (which FYI it does not, with stock IoT core image) only to find that I was then unable to use the configuration tool to change the mode any more. Same issue as above.

Anyway, I decided to grab a software USB protocol analyzer to take a look at what was going on. I could see that when the AR config tool tried to open the device, the call to CreateFile() failed two or three times with ERROR_SHARING_VIOLATION before eventually succeeding. My guess is that it first tries to access the device with the highest set of privileges (read + write), fails, and falls back to read only or similar.

I then wanted to understand why the error was occurring since the switch to digitizer, and grabbed a copy of Process Explorer from Technet to find out which processes had open handles to the devices symbolic path name. Turns out the System process had exclusive access to the device, and I could not close the handles in order to run the AR config tool.

I have speculated that what is happening here is that as soon as Windows 8 detects the digitizer it obtains exclusive access in order to start streaming position data, and it is expected that no other software should need access to the device. With this in mind this issue is not the fault of Adafruit or the guys who make the chip, it seems to be Windows grabbing the device before anything else can.

My solution to this problem, while a bit long winded, was fairly straight forward. If you have access to a Windows XP machine, just use that. You will find that it does not have this issue and the AR config tool will just work. If you do not, do the following:

1. Download and install Virtual Box
2. Follow this guide to set up a Windows XP virtual machine:

http://lifehacker.com/5965889/how-to-ru ... -windows-8

3. Install the AR config tool on the VM
4. Enable USB device passthrough of the digitizer into the VM
5. Run the tool and change the devices mode back to mouse
6. Enable USB device passthrough of the mouse into the VM (it will have a different PID now)
7. Run calibration to get the touchscreen back into a working state.

Hope that helps someone else out.

-Adam.

[adafruit_support_mike]

Nice piece of detective work.. thanks for posting the writeup. I'm sure you've saved someone a few hours of headaches in the future. ;-)

[adafruit2]

Hi all,

I came across this thread the other day after winding up in the exact same situation and thought I would post the outcome of my findings and resolution to the issue in case it helps the next person this will inevitably happen to.

So I recently bought a Rasberry Pi 2 with the intention of installing Windows 10 IoT core and playing with some universal app development and the Adafruit 2260 with touchscreen seemed like a good match for my needs. This display comes with the AR1100 as a backpack module.

After setting up the Pi and having a play I was curious to see if it would work in digitizer mode (which FYI it does not, with stock IoT core image) only to find that I was then unable to use the configuration tool to change the mode any more. Same issue as above.

Anyway, I decided to grab a software USB protocol analyzer to take a look at what was going on. I could see that when the AR config tool tried to open the device, the call to CreateFile() failed two or three times with ERROR_SHARING_VIOLATION before eventually succeeding. My guess is that it first tries to access the device with the highest set of privileges (read + write), fails, and falls back to read only or similar.

I then wanted to understand why the error was occurring since the switch to digitizer, and grabbed a copy of Process Explorer from Technet to find out which processes had open handles to the devices symbolic path name. Turns out the System process had exclusive access to the device, and I could not close the handles in order to run the AR config tool.

I have speculated that what is happening here is that as soon as Windows 8 detects the digitizer it obtains exclusive access in order to start streaming position data, and it is expected that no other software should need access to the device. With this in mind this issue is not the fault of Adafruit or the guys who make the chip, it seems to be Windows grabbing the device before anything else can.

My solution to this problem, while a bit long winded, was fairly straight forward. If you have access to a Windows XP machine, just use that. You will find that it does not have this issue and the AR config tool will just work. If you do not, do the following:

1. Download and install Virtual Box
2. Follow this guide to set up a Windows XP virtual machine:

http://lifehacker.com/5965889/how-to-ru ... -windows-8

3. Install the AR config tool on the VM
4. Enable USB device passthrough of the digitizer into the VM
5. Run the tool and change the devices mode back to mouse
6. Enable USB device passthrough of the mouse into the VM (it will have a different PID now)
7. Run calibration to get the touchscreen back into a working state.

Hope that helps someone else out.

-Adam.

Thx by the way, we do have some linux/Raspi code that will let you change modes, check it out here:

https://gist.githubusercontent.com/lady ... 1100cal.py

Code: Select all

try:
        # turn into Mouse
        #                             bReq, wVal,   wIndex, data
        ret = dev.ctrl_transfer(0x21, 0x09, 0x0003, 0x0000, [0x55, 0x01, 0x71])
        if (ret == 3):
                print "Turned into Mouse!"
except:
        # failed to get data for this request
        print "Failed to turn into Mouse"
        exit(-1)

[adam_w]

Ah that's awesome thanks for sharing... I'm more of a Microsoft guy than a Linux guru (as you may have gleamed) and I tried to write a quick app which did exactly the same thing under Windows by installing the WinUSB generic driver against the digitizer, then sending the 0x55 0x01 0x71 command sequence to the device. For future reference in case people stumble upon this, the info is here on page 24:

http://ww1.microchip.com/downloads/en/D ... 41606B.pdf

Sadly I was uncertain at the time what values to use for the other ControlTransfer parameters (request type, request, value, index) and gave up after a short while. It would be interesting to have another go at some point now I know what to send and perhaps make a Windows based recovery tool available for others to try.

-Adam

[kapsen]

Hi all,

I came across this thread the other day after winding up in the exact same situation and thought I would post the outcome of my findings and resolution to the issue in case it helps the next person this will inevitably happen to.

So I recently bought a Rasberry Pi 2 with the intention of installing Windows 10 IoT core and playing with some universal app development and the Adafruit 2260 with touchscreen seemed like a good match for my needs. This display comes with the AR1100 as a backpack module.

After setting up the Pi and having a play I was curious to see if it would work in digitizer mode (which FYI it does not, with stock IoT core image) only to find that I was then unable to use the configuration tool to change the mode any more. Same issue as above.

Anyway, I decided to grab a software USB protocol analyzer to take a look at what was going on. I could see that when the AR config tool tried to open the device, the call to CreateFile() failed two or three times with ERROR_SHARING_VIOLATION before eventually succeeding. My guess is that it first tries to access the device with the highest set of privileges (read + write), fails, and falls back to read only or similar.

I then wanted to understand why the error was occurring since the switch to digitizer, and grabbed a copy of Process Explorer from Technet to find out which processes had open handles to the devices symbolic path name. Turns out the System process had exclusive access to the device, and I could not close the handles in order to run the AR config tool.

I have speculated that what is happening here is that as soon as Windows 8 detects the digitizer it obtains exclusive access in order to start streaming position data, and it is expected that no other software should need access to the device. With this in mind this issue is not the fault of Adafruit or the guys who make the chip, it seems to be Windows grabbing the device before anything else can.

My solution to this problem, while a bit long winded, was fairly straight forward. If you have access to a Windows XP machine, just use that. You will find that it does not have this issue and the AR config tool will just work. If you do not, do the following:

1. Download and install Virtual Box
2. Follow this guide to set up a Windows XP virtual machine:

http://lifehacker.com/5965889/how-to-ru ... -windows-8

3. Install the AR config tool on the VM
4. Enable USB device passthrough of the digitizer into the VM
5. Run the tool and change the devices mode back to mouse
6. Enable USB device passthrough of the mouse into the VM (it will have a different PID now)
7. Run calibration to get the touchscreen back into a working state.

Hope that helps someone else out.

-Adam.

Thank you, been trying to get this to work on Windows 10 for a few days. Just followed your steps and had it working in under 30 min. Thanks again!

[subzer0]

I accidentally (don't ask) switched the AR to HID mode on the Pi and was able to set it back to Mouse mode using the AR Configuration Utility on Windows 10.