atmel-maxtouch / mxt-app

Command line utility for Atmel maXTouch devices

NAME

mxt-app - command line utility for maXTouch devices

SYNOPSIS

mxt-app [command] [options]...

DESCRIPTION

mxt-app is a utility for managing Atmel maXTouch touch controllers and other devices that support Atmel Object Based Protocol.

If no command is not given, mxt-app will provide an interactive menu based interface.

OBJECT PROTOCOL

The Atmel Object Based Protocol defines how device registers (normally accessed via I2C) are mapped to different functions within the devices. This interface organises the register map into separate objects each of which is given a T number. mxt-app can inspect and alter the object configuration, and view diagnostic data, while the device is running.

For a description of object protocol, see Atmel AT42QT1085 Object Protocol Guide, available from atmel.com.

The meaning of the configuration bytes within the objects may be found in the Protocol Guide documentation released with each device, and is only provided by Atmel under NDA.

GENERAL COMMANDS

-h [--help] : Display a brief summary of available options and exit.

-i [--info] : Print the ID information and object table.

-M [--messages] [*timeout*] : Prints the messages until timeout seconds have passed. If no timeout is provided, continue until user presses Ctrl-C. Zero timeout reads once. Provide -F [--msg-filter] option to filter by a specific object.

-F [--msg-filter] *TYPE* : Filters messages by object TYPE.

--reset : Reset device.

--calibrate : Send calibrate command.

--backup[*=COMMAND*] : Backup configuration to NVRAM where the optional argument, COMMAND, is the BACKUPNV command.

-g : Write Golden Reference calibration to NVRAM.

--self-cap-tune-config : Tune and calibrate the self capacitance settings and store them to the device configuration.

--self-cap-tune-nvram : Tune and calibrate the self capacitance settings and store them to NVRAM without updating the Config Checksum.

--version : print version of mxt-app.

--block-size *BLOCKSIZE* : Sets the i2c block size.

CONFIGURATION FILE COMMANDS

--load *FILE* : Upload config from FILE, write it to NVRAM, and reset device. The configuration may be in .xcfg or OBP_RAW format.

--save *FILE* : Save config to FILE in either OBP_RAW or .xcfg format.

--checksum *FILE* : Read the contents of FILE and recalculate the configuration checksum.

REGISTER READ/WRITE COMMANDS

-R [--read] : Read data from the device.

-W [--write] : Write data to the device.

-n [--count] *COUNT* : read/write COUNT registers

-f [--format] : format register output

-I [--instance] *INSTANCE* : select object INSTANCE

-r [--register] *REGISTER* : start at REGISTER (offset in object when used with TYPE)

-T [--type] *TYPE* : select object TYPE

--zero : zero all configuration settings

EXAMPLES

Read info block:

$ mxt-app -R -n7 -r0
82 19 11 AA 18 0E 16

Read T7 Power Config object:

$ mxt-app -R -T7
32 FF 05 43

Zero first two bytes of T7:

$ mxt-app -W -T7 0000

Read T7 Power Config object, formatted output:

$ mxt-app -R -T7 --format
GEN_POWERCONFIG_T7

00: 0x00    0 0000 0000
01: 0x00    0 0000 0000
02: 0x05    5 0000 0101
03: 0x43   67 0100 0011

TCP SOCKET COMMANDS

mxt-app supports connection over TCP using a ASCII protocol which allows mxt-app to act as a bridge so that Atmel proprietary tools such as Object Server can access the device.

-C [--bridge-client] *HOST* : Connect over TCP to HOST

-S [--bridge-server] : Start TCP socket server

-p [--port] PORT : TCP port (default 4000)

BOOTLOADER COMMANDS

--bootloader-version : Query and print ID and version of bootloader.

--flash *FIRMWARE* : Flash FIRMWARE to device. The firmware file should be in .enc format.

--reset-bootloader : Reset device in bootloader mode. In bootloader mode the device will cease normal operation until a firmware is sent. The I2C address or USB PID will change. The only valid command in this mode is --flash. A hard power cycle will return the device to normal Object Protocol mode, unless the firmware image is corrupted. This command is only provided for debugging purposes: in most cases --flash will manage the change to/from bootloader mode before/after flash.

--firmware-version *VERSION* : The .enc file format does not provide the firmware version in a form available to mxt-app. If it is provided via this switch, mxt-app can check firmware VERSION before and after flash. It will skip the flash process if the firmware version is already correct. It will also check for a successful flash on completion. The version must be provided in the format 1.0.AA.

T25 SELF TEST OPTIONS

The Self Test T25 object runs self-test routines in the device to find faults in the sense lines and electrodes. The Self Test T25 object runs a series of test sequences.

-t [--test] : Run all self tests.

-t*XX* [--test=*XX*] : Run individual self test specified by the CMD hex value.

-t01 : run analog power test.

-t11 : run pin fault test.

-t12 : run pin fault 2 test.

-t13 : run AND gate test.

-t17 : run signal limit test.

-t20 : run gain test.

-t21 : run offset fault test.

T37 DIAGNOSTIC DATA OPTIONS

Capture frames of diagnostic data. The default mode is to capture touch deltas. Self capacitance measurements are only available on some devices.

--debug-dump *FILE* : The T37 Diagnostic Data object provides raw access to touch reference/delta measurements from the touch screen. Diagnostic data is written to FILE in CSV format. Format 0 is compatible with the Atmel Hawkeye utility.

--frames *N* : Capture N frames of data.

--instance *N* : Capture object instance N. Defaults to instance 0.

--format *N* : Capture using Format 0 or 1. Format 0 - Outputs all nodes in single line (X0Y0, X0Y1, ... X1Y0). Format 1 - Outputs in (X) row and (Y) column format.

--references : Capture references data.

--self-cap-signals : Capture self cap signals.

--self-cap-deltas : Capture self cap deltas.

--self-cap-refs : Capture self cap references.

--active-stylus-deltas : Capture active stylus deltas.

--active-stylus-refs : Capture active stylus references.

T68 SERIAL DATA COMMANDS

--t68-file *FILE* : Upload FILE to the device via the T68 Serial Data object.

--t68-datatype *DATATYPE* : Set DATATYPE of the file. This will be automatically detected from the file itself in most cases.

BROKEN LINE DETECTION

The broken line test scans the diagnostic data to identify touch sensor defects.

--broken-line : Run the broken line detection algorithm on the device

--dualx : Indicate if sensor X lines are double connected

--x-center-threshold N : Set threshold for X lines in center of sensor to N percent

--x-border-threshold N : Set threshold for X lines at edge of sensor to N percent

--y-center-threshold N : Set threshold for Y lines in center of sensor to N percent

--y-border-threshold N : Set threshold for Y lines at edge of sensor to N percent

--pattern *PATTERN* : set sensor PATTERN material to ITO or Xsense

SENSOR VARIANT ALGORITHM

The sensor variant algorithm calculates all nodes of a channel to find the trend line of the reference. A comparison is done between the real and expected sensor reference.

--sensor-variant : Perform the Sensor Variant algorithm

--dualx : Indicate if sensor X lines are double connected

--fail-if-any : Fail the Sensor Variant test on any defects

--max-defects N : Maximum No. of continuous defects

--upper-limit N : Upper limit for regression, in percentage %

--lower-limit N : Lower limit for regression, in percentage %

--matrix-size N : The allowed matrix size

FINDING AND SPECIFYING DEVICE

By default mxt-app will scan available devices and connect to the first device it finds.

-q [--query] : Scan for devices and output a list.

-d [--device] *DEVICESTRING* : Connect to a particular device specified by DEVICESTRING which is given in the same format as output by --query.

There are three connection methods supported for hardware access:

sysfs

This is used in conjunction with the Linux kernel driver. It accesses sysfs attributes under the directory

/sys/bus/i2c/drivers/dddddddd/b-00xx/

Where

d : driver name - atmel_mxt_ts, Atmel MXTXXXX, etc

b : i2c adapter

xx : i2c address

A specific USB device can be specified by giving a device option -d sysfs:PATH as given by -q/--query option

The sysfs attributes used under this directory are

mem_access : Access to raw I2C address space.

debug_enable : Output messages from the device to dmesg log as hexadecimal.

debug_v2_enable, debug_msg, debug_notify : Optional improved binary interface to retrieve messages

They are provided when using the Atmel kernel driver from github, and may be supported by other devices.

USB

Many maXTouch devices support a USB mode which reports touches via USB HID. In addition, evaluation boards may use a "bridge chip" which interfaces I2C to the same protocol.

USB mode will be built by autotools when libusb is available.

A specific USB device can be specified by giving a device option -d usb:001-003 which corresponds to the bus and device numbers given by the -q/--query option and lsusb.

I2C debug interface

Devices can be accessed directly via the i2c-dev I2C debug interface by giving adapter and address on command line.

The i2c-dev interface is documented in the Linux kernel source, in Documentation/i2c/dev-interface

The I2C debug interface support must be enabled using the CONFIG_I2C_CHARDEV kernel configuration option. It is enabled on a system if files /dev/i2c-* are present.

To use i2c-dev, provide a device string such as -d i2c-dev:1-004a.

Messages from the maXTouch devices are read by polling. If a kernel driver is also present on the system, reading messages on interrupt, then no messages will be received by the tool. A workaround is to set T18.COMMAND (byte 1) to 2 "Force the CHG line high (inactive)" so the kernel driver does not receive an interrupt.

There is no scanning support. This is because reading from every possible maXTouch address on every I2C bus might adversely affect some unrelated hardware that does not understand Object Protocol. You must manually identify the correct adapter and address by reference to the protocol guide or to the platform setup.

It is possible to use the --flash command with a device already in bootloader mode, by specifying the bootloader address.

HIDRAW

The hidraw backend supports maXTouch devices which connect using USB or HID over I2C.

The hidraw interface is documented in the Linux kernel source, in Documentation/hid/hidraw.txt

The device must have /dev/hidraw raw HID device support enabled using the CONFIG_HIDRAW kernel configuration option.

To use hidraw, provide a device string such as -d hidraw:/dev/hidraw0.

There is no scanning support.

Bootloading is not supported in this mode.

DEBUG OPTIONS

-v [--verbose] *LEVEL* : set debug level. LEVEL is one of 0 (Silent), 1 (Warnings and Errors), 2 (Info - default), 3 (Debug), 4 (Verbose). Debug and Verbose are only available if built in.

EXIT VALUES

0 : Success

1 : Internal error/assert

2 : Input/output error

3 : Memory allocation failure

4 : Timeout

5 : Could not find a device or device went away

6 : Permission denied

7 : Operation not allowed for this device type

8 : Interrupt function call

9 : Object not available on device

10 : Received unexpected invalid message from message processor

11 : Self test invalid test command

12 : Self test AVdd Analog power is not present

13 : Self test Pin fault

14 : Self test AND Gate Fault

15 : Self test Signal limit fault

16 : Self test Gain error

17 : Information block checksum error

18 : Bootloader already unlocked

19 : Bootloader CRC failure (transmission failure)

20 : File format error

21 : Device firmware already required version

22 : Could not identify bootloader address

23 : Version on device did not match version given after bootloading operation

24 : Device did not reset

25 : Device in unexpected state

26 : Incorrect command line parameters or menu input given

27 : Bridge TCP protocol parse error

28 : Bridge connection error

29 : Serial data download failed

30 : No such file or directory

31 : Error processing self cap command

COMPILING FROM SOURCE

To download the source code using git:

git clone https://github.com/atmel-maxtouch/mxt-app.git

There are two build harnesses, for Android and autotools:

Android

To download libusbdroid submodule:

git submodule init
git submodule update

Or to build without usb support:

MXTAPP_NO_USB_SUPPORT := true

To compile using Android NDK:

ndk-build

To enable debug:

ndk-build NDK_DEBUG=1

To disable usb support:

ndk-build MXTAPP_NO_USB_SUPPORT=true

To enable PIE support (for Android L):

ndk-build APP_PLATFORM=android-16

Binaries will be placed in libs/

The Android NDK is available from https://developer.android.com/tools/sdk/ndk/

Running on Android

adb push libs/armeabi/mxt-app /data/local/tmp/
adb shell /data/local/tmp/mxt-app [command]

If executable permissions have not been set, run:

adb shell chmod 777 /data/local/tmp/mxt-app

autotools

To compile using autotools:

./autogen.sh && make

To cross-compile:

./autogen.sh --host=arm-linux-gnueabi && make

or, 

./autogen.sh --host=arm-linux-gnueabihf && make

To enable debug:

./autogen.sh --enable-debug

To enable generation of the man page using pandoc:

./autogen.sh --enable-man

To build the doxygen documentation (this requires doxygen and graphviz to be installed):

make doc

VERSION NUMBERING

A version number is generated by git describe during the build process and is reported by --version and to debug logs.

A typical version might be 1.15-29-g8321 which means, 29 commits after the release tag 1.15, with a git SHA id beginning with 8321.

If the source is not checked out using git (for example by clicking on the github "Download ZIP" link), then the version from the file VERSION in the source archive is used.

The suffix -mod is appended if there are uncommitted changes in the source code.

TROUBLESHOOTING

klogctl error

If you see the warning

W: klogctl error 1 (Operation not permitted)

this indicates that mxt-app has been unable to retrieve messages from dmesg. Various features will not work properly. It may be possible to unrestrict dmesg by doing

# echo 0 > /proc/sys/kernel/dmesg_restrict

mxt-app's Issues

handle_messages() misunderstands the value returned by snprintf()

Consider this code: [

length = snprintf(mxt->msg_string, sizeof(mxt->msg_string),
                  MXT_ADB_CLIENT_MSG_PREFIX);

for (j = 0; j < num_bytes; j++) {
  length += snprintf(mxt->msg_string + length,
                     sizeof(mxt->msg_string) - length,
                     "%02X", databuf[j]);
}

]

`man snprintf' says: "The functions snprintf() and vsnprintf() do not write more than size bytes (including the terminating null byte ('\0')). If the output was truncated due to this limit, then the return value is the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated."

If the buffer runs out of space and snprintf() truncates the output, `length' will contain a value larger than the maximum number of characters snprintf() was asked to output. On the next iteration through the loop, (sizeof(mxt->msg_string) - length) will be slightly negative. Since it's passed to snprintf() as size_t, which is unsigned, this call will give snprintf() permission to write a very large number of characters and overflow the buffer.

failed firmware update in bootmode

Firmware update failure logs --
Version:1.18
Opening firmware file /fs/mp/etc/system/config/mXT540EAT_0x0C_2.1.AA_RECOVERY.enc
Using bootloader address
Registered i2c-dev adapter:2 address:0x27
Unlocking bootloader
Bootloader unlocked
Sending frames...
Bootloader ID:10 Version:3
__dm_write_bl_reg16: i2c retry
Bootloader reports FRAME_CRC_FAIL
Frame 2: CRC fail, retry 1
Sent 20 frames, 4988 bytes
Sent 40 frames, 10508 bytes
Sent 60 frames, 16028 bytes
Sent 80 frames, 21548 bytes
Sent 100 frames, 27068 bytes
Sent 120 frames, 32588 bytes
....
Sent 5720 frames, 1578188 bytes
.....goes on and on

i2c error seems to have happened, leading to 'Bootloader reports FRAME_CRC_FAIL'.

In send_frames(..), I see this is because frame_retry is NOT being reset to 0 after increment on FRAME_CRC_FAIL error. This leads to the below condition never being met and thus never picking the next byte from the firmware file:
if (frame_retry == 0){
if (get_hex_value(fw, &buffer[0]) == EOF)....
}

Fix-
static int send_frames(struct flash_context *fw)
{
.....
else {
frame_retry = 0; <------Fix: set to 0 here
mxt_verb(fw->ctx, "CRC pass");
frame++;
bytes_sent += frame_size;
if (frame % 20 == 0) {
mxt_info(fw->ctx, "Sent %d frames, %d bytes", frame, bytes_sent);
} else {
mxt_verb(fw->ctx, "Sent %d frames, %d bytes", frame, bytes_sent);
}
}
}
Please leave your comments if this is correct or have sugestions

Config CRC is sometimes zero when saving the config

The code issues a REPORTALL to get the config CRC from the T6 status message. However, sometimes the device is in deep sleep or MSG retrieval isn't working, and the message never arrives.

mxt-app USB detection failure

USB detection is failing with "Cannot find a control interface" on certain USB S series products

Firmware update using USBtoI2C bridge not working

A firmware update using the Microchip USBtoI2C bridge board option does not work.
Fails to find device after bootloader command is sent.

T10 Signal Limit reports back wrong bytes

T10 signal limit reports back wrong bytes when error occurs.
Error message needs to be fixed.

mxt_err(mxt->ctx, "T%d instance[%d] failed signal limit test", msg[2], msg[3]);

Convert a .xcfg config to raw format

mxt-app should be able to convert a .xcfg file to OBP_RAW without a device being present.

Suggested command line:

mxt-app --xcfg2raw test.xcfg test.raw

Test command often times out

In v1.18 the test command (mxt-app --test=01) often (but not always times out)
This is when using the sysfs v1 interface.

The reason is that the test command calls, mxt_msg_reset()
Which does,
int sysfs_msg_reset(struct mxt_device *mxt)
{
int ret;

mxt->sysfs.mtimestamp = 0;
ret = get_uptime(&mxt->sysfs.timestamp);

return ret;
}

get_uptime() is implemented using the sysinfo() system call which always rounds up to the next second.

This value is then used to filter out any dmesg entries before this time.
The result is that , unless the comand is issued close enough to the end of the second for the log message generated by the kernel as the test reponse to be in the next second the message is lost and the command times out.

Example with some logs added:
root@PC12445-BES:~# mxt-app -v 2 --test=01
Version:1.18
Registered sysfs path:/sys/bus/i2c/drivers/atmel_mxt_ts/0-004a
Enabling self test object

Disabling noise suppression
TOUCH_MULTITOUCHSCREEN_T9[0] enabled
UPSIGLIM:30000
LOSIGLIM:20000
TOUCH_KEYARRAY_T15[0] disabled
UPSIGLIM:0
LOSIGLIM:0
Running Analog power test
@mf@ found 0 new messages total=344 matched=341 new=0 mxt=0 first=0.0 last=3560.793171 ts=3561.0
@mf@ found 0 new messages total=344 matched=341 new=0 mxt=0 first=0.0 last=3560.793171 ts=3560.793171
...
Timeout

ts above is the value of mxt->sysfs.timestamp in sysfs_get_msg_count()
it was set to 3561 by sysfs_msg_reset() hence the reply is ignored...

dmesg shows that the response WAS received 3560.791631
root@PC12445-BES:~# dmesg | tail
[ 3560.791631] atmel_mxt_ts 0-004a: MXT MSG: 0e fe 00 00 00 00 00 00
[ 3560.793171] atmel_mxt_ts 0-004a: MXT MSG: ff fe 00 00 00 00 00 00

When self test fails due to pinfault "Unrecognized error is displayed"

When running mxt-app -t on a mxt224e with a pinfault error the error message "FAIL: Unrecognized error" is displayed.

Adding a log to the code shows that the error code is 0x11, as described in the mxt224e protocol guide. However in mxt-app.h there is:

define SELF_TEST_PIN_FAULT 0x12

Either this is a typo or a difference between other chips and the mxt224e

if-clause is always true

File:
mxt-app/src/mxt-app/bootloader.c

Variable:
unsigned char bootloader_id;

Expression:
if (bootloader_id | 0x20) { ... } else { ... }

The if-clause will always evaluate to true. Looks strange.

/rob

Issue interfacing with devices using HA protocol without Linux driver present

Need to update mxt-app to handle HA protocol if flags are not present

AOSP build still broken

Top-level Android.mk is in the wrong place (see issue #60), so build (NDK r12b) breaks with:

including ./external/mp4parser/Android.mk ...
including ./external/mtpd/Android.mk ...
including ./external/mxt-app/jni/Android.mk ...
including ./external/mxt-app/lib/libusbdroid/Android.mk ...
build/core/base_rules.mk:157: *** external/mxt-app/lib/libusbdroid/code/src/LibUSBDroid/jni: MODULE.TARGET.STATIC_LIBRARIES.libusbdroid already defined by external/mxt-app/jni/../lib/libusbdroid/code/src/LibUSBDroid/jni. Stop.

make failed to build some targets (40 seconds)

mxt-app on raspberry pi

Is it possible to run this utility on Raspberry Pi?

The board has an I2C interface so theoretically it should be possible to use it to communicate with mxt640x chips.

I tried autotool but the procedure ends with an error.

Restore configuration after updating the firmware

Cannot write to objects with multiple instances

Cannot write to objects with multiple instances using read and write commands in the mxt-app menu. The wrong instance is being captured.

AOSP build still broken

Hi,

By cherry-picking my patch you apparently didn't move the Android.mk to the top folder.

However, not having it in the top folder breaks the build with the following issue:
build/core/base_rules.mk:183: *** external/mxt-app/lib/libusbdroid/code/src/LibUSBDroid/jni: MODULE.TARGET.STATIC_LIBRARIES.libusbdroid already defined by external/mxt-app/jni/../lib/libusbdroid/code/src/LibUSBDroid/jni.

The reason is that Android parses all the folder while searching for Android.mk. As soon as it hits one, it depends on that Android.mk to point to sub folders.

In your case, the jni/Android.mk includes all the other Android.mk (not in sub folders) and then the Android build system still parses the other folder, hence see twice the same Android.mk.

So it either needs to be put at top level or removed completely.

Regards,
Gary

I2C error when all tests, broken line, sensor variant invoked through script

I am calling all test, broken line , sensor variant test back to back in a script and this results in an i2c error. Attached script test_nodelay prints the error on the console. The error occurs after the first test. The second one fails
However if I put a delay as in the test.sh script everything works fine.

Details of the setup:-
mxt-app version mxt-app 1.28-19-g4e9daa7
kernel version :- 4.14

Attached is a log file of the error:- mxt-app-error

Note that the commands are tried by adding a reset command after every test still the same behavior.

Add command line option for I2C block size

Read and write registers in same format on command line

Currently, mxt-app --write doesn't expect spaces between bytes. It should, so it's easier to round-trip.

Tests fail to compile

gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2 -I./src -fvisibility=hidden -ffunction-sections -fdata-sections -Wall -Werror -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wsign-compare -Wchar-subscripts -Wstrict-prototypes -Wwrite-strings -Wshadow -Wformat-security -Wtype-limits -DMXT_VERSION=\"1.33\" -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -g -O2 -ffile-prefix-map=/build/mxt-app-1.33=. -fstack-protector-strong -Wformat -Werror=format-security -c -o src/mxt-app/run_unit_tests-menu.o `test -f 'src/mxt-app/menu.c' || echo './'`src/mxt-app/menu.c
src/mxt-app/menu.c: In function 'read_object_command':                          
src/mxt-app/menu.c:115:21: error: unused variable 'obj' [-Werror=unused-variable]
115 |   struct mxt_object obj;
    |                     ^~~
gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2 -I./src -fvisibility=hidden -ffunction-sections -fdata-sections -Wall -Werror -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wsign-compare -Wchar-subscripts -Wstrict-prototypes -Wwrite-strings -Wshadow -Wformat-security -Wtype-limits -DMXT_VERSION=\"1.33\" -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -g -O2 -ffile-prefix-map=/build/mxt-app-1.33=. -fstack-protector-strong -Wformat -Werror=format-security -c -o src/mxt-app/run_unit_tests-bootloader.o `test -f 'src/mxt-app/bootloader.c' || echo './'`src/mxt-app/bootloader.c
cc1: all warnings being treated as errors
make[2]: *** [Makefile:1205: src/mxt-app/run_unit_tests-menu.o] Error 1
make[2]: *** Waiting for unfinished jobs....
src/mxt-app/bootloader.c: In function 'mxt_bootloader_init_chip':               
src/mxt-app/bootloader.c:423:3: error: enumeration value 'E_SPI' not handled in
switch [-Werror=switch]                                                           
423 |   switch (fw->conn->type) {
     |   ^~~~~~                                                                cc1: all warnings being treated as errors
make[2]: *** [Makefile:1219: src/mxt-app/run_unit_tests-bootloader.o] Error 1 
make[1]: *** [Makefile:1807: check-am] Error 2
make[1]: Leaving directory '/build/mxt-app-1.33'

Add percentage complete to firmware flash

It would be good if the flash output could give an indication of progress.

mxt_convert_hex_test fails on 32bit architectures

The test is failing because of the undefined behaviour of strcpy() when dest buffer is smaller than src buffer.
Bug is in mxt_convert_hex_test function in /src/test/test_utilfuncs.c file.
Destination buffer (hex) is 4 bytes, and on strcpy(hex, "0FAB"); there is no space left to copy the null terminator.

Bug with proposed solution is reported on Debian: https://bugs.debian.org/828953

Extended config bytes in maxtouch device written to 0x00 is unexpected

As reported, extended config bytes in maxtouch device are written to 0x00, which is unexpected. The extended bytes should be left untouched unless forced to be cleared.

Info checksum error read=0005D6 with mxt640UD

I'm running mxt-app from a raspberry pi using i2c native interface with a mxt640
It actually works on a mxt640U and i get following responses:

raspberrypi@raspberrypi:~/mxt-app $ ./mxt-app -d i2c-dev:1-004b -i

Device registered on i2c-dev adapter:1 address:0x4b

Family: 166 Variant: 1 Firmware V1.1.AA Objects: 41
Matrix size: X32Y20
Information Block CRC: 0xFE4DE3

Type Start Size Instances ReportIds Name
-----------------------------------------------------------------
T37   256   130     1        0-0    DEBUG_DIAGNOSTIC_T37
T44   386     1     1        0-0    SPT_MESSAGECOUNT_T44
T5    387    11     1        0-0    GEN_MESSAGEPROCESSOR_T5
T6    398     7     1        1-1    GEN_COMMANDPROCESSOR_T6
T68   405    73     1        2-2    SERIAL_DATA_COMMAND_T68
T38   478    64     1        0-0    SPT_USERDATA_T38
T71   542   200     1        0-0    SPT_DYNAMICCONFIGURATIONCONTAINER_T71
T110  742    40    12        0-0    SPT_SELFCAPTUNINGPARAMS_T110
T7   1222     7     1        0-0    GEN_POWERCONFIG_T7
T8   1229    15     1        0-0    GEN_ACQUISITIONCONFIG_T8
T15  1244    11     1        3-3    TOUCH_KEYARRAY_T15
T18  1255     2     1        0-0    SPT_COMMSCONFIG_T18
T19  1257    16     1        4-4    SPT_GPIOPWM_T19
T25  1273    16     1        5-5    SPT_SELFTEST_T25
T40  1289     7     1        0-0    PROCI_GRIPSUPPRESSION_T40
T42  1296    14     1        0-0    PROCI_TOUCHSUPPRESSION_T42
T43  1310    15     1        6-6    SPT_DIGITIZER_T43
T46  1325    18     1        7-7    SPT_CTECONFIG_T46
T47  1343    47     1        0-0    PROCI_STYLUS_T47
T56  1390    36     1        8-8    PROCI_SHIELDLESS_T56
T61  1426     5     6        9-14   SPT_TIMER_T61
T65  1456    23     3       15-17   PROCI_LENSBENDING_T65
T70  1525    10    20       18-37   SPT_DYNAMICCONFIGURATIONCONTROLLER_T70
T72  1725    89     1       38-38   PROCG_NOISESUPPRESSION_T72
T77  1814     2     1        0-0    SPT_CTESCANCONFIG_T77
T78  1816    12     1        0-0    PROCI_GLOVEDETECTION_T78
T79  1828     4     3        0-0    SPT_TOUCHEVENTTRIGGER_T79
T80  1840    14     1       39-39   PROCI_RETRANSMISSIONCOMPENSATION_T80
T81  1854    18     2       40-41   PROCI_UNLOCKGESTURE_T81
T93  1890    30     1       42-42   PROCI_TOUCHSEQUENCELOGGER_T93
T100 1920    68     1       43-60   TOUCH_MULTITOUCHSCREEN_T100
T104 1988    11     1        0-0    SPT_AUXTOUCHCONFIG_T104
T108 1999    75     1       61-61   PROCG_NOISESUPSELFCAP_T108
T109 2074     9     1       62-62   SPT_SELFCAPGLOBALCONFIG_T109
T111 2083    32     2        0-0    SPT_SELFCAPCONFIG_T111
T112 2147     5     1       63-63   PROCI_SELFCAPGRIPSUPPRESSION_T112
T113 2152     3     1        0-0    SPT_PROXMEASURECONFIG_T113
T115 2155    20     1       64-64   PROCI_SYMBOLGESTURE_T115
T116 2175   255     1        0-0    SPT_SYMBOLGESTURECONFIG_T116
T121 2430     3     1        0-0    PROCI_SENSOR_CORRECTION_T121
T132 2433    18     1       65-65   SPT_MESSAGEFILTER_T132

Connecting the same interface with a mxt640UD, i'm experiencing the following issue:

raspberrypi@raspberrypi:~/mxt-app $ ./mxt-app -d i2c-dev:1-004b -i

Device registered on i2c-dev adapter:1 address:0x4b
**Info checksum error calc=04DFFC read=0005D6**
raspberrypi@raspberrypi:~/mxt-app $ 

If i repeat the command i get checksum calculation changed and read is still the same.

In both cases the device answer to 0x4B address:

raspberrypi@raspberrypi:~/mxt-app $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- 4b -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --        

Do you have any tips i can try in order to communicate with mxt640UD?

Support flashing of ACPI devices

With devices in ACPI mode, mxt-app is unable to look up the I2C address so that it can access the device in bootloader mode via i2c-dev.

mxt-app doesn't auto scan with intel i2c drivers

mxt-app expects to see attributes adapter-address under /sys/bus/i2c/devices. On Intel platforms, this looks like i2c-ATML100:00 or similar, due to the way that the device is initialised via ACPI. Therefore autoscan doesn't work.

It's possible to work around by passing the sysfs path directly with -d sysfs:/sys/bus/i2c/devices/i2c-ATML100:00

If the device doesn't have the sysfs interface, then the i2c-dev option can still be used, eg -d i2c-dev:1-004a, but you have to work out the adapter from sysfs and the address by manually guessing between 4a and 4b.

AUR Package for Arch Linux

Found this by way of raphael/linux-samus#73. With the new kernel on the Pixel 2, we need to reset the touchpad on boot / resume.

Ideally I would like to install this as a package from the AUR (then add a systemd hook to deal with the touchpad issue).

Would you consider adding this to the AUR?

Add feature to convert .enc to .fw format

It would be useful if mxt-app could convert firmware formats rather than relying on xxd.

Update CRC of .xcfg file without device

It should be possible to update the CRC of a .xcfg file without having an attached device

obp-utils depends on pandoc

It seems obp-utils uses pandoc when installing man pages. No other recipe provides pandoc, and I guess it's taken from the host.

It works at windows,

Does it work on Windows, or is there a way to download it on Windows?

Thank you,

Debug dump format 0 does not work

Using format 0 for debug-dump feature is not working.
Returns same format as format 1.
ctx->fformat variable not being used correctly

Display configuration checksums, NVRAM and in-memory

Update configuration using extended format and verify it