Interfacing

5" PCAP Lemaker Screen Occasionally starts up un-responsive

7 1304
Has anyone used the PCAP Screen? I've noticed that starting up 1 out of 4 times results in the TS un-responsive.

I've added an additional modprobe ft5x_ts to my python code. Would it be helpful to unload and reload instead to ensure Touchscreen is enabled?

Having an occasional un-responsive touchscreen sucks, rebooting fixes it obviously. But thats an extra 30 seconds to wait.


Edited by remote.syst3m at Jan 10, 2016 21:59

Here is a working Dmesg:

[    7.731528] ===========================ft5x_ts_init=====================
[    7.736088] ctp_fetch_sysconfig_para.
[    7.745493] ctp_fetch_sysconfig_para: after: ctp_twi_addr is 0x38, dirty_addr_buf: 0x38. dirty_addr_buf[1]: 0xfffe
[    7.749723] ctp_fetch_sysconfig_para: ctp_twi_id is 3.
[    7.754182] ctp_fetch_sysconfig_para: screen_max_x = 800.
[    7.758623] ctp_fetch_sysconfig_para: screen_max_y = 480.
[    7.763066] ctp_fetch_sysconfig_para: revert_x_flag = 0.
[    7.767464] ctp_fetch_sysconfig_para: revert_y_flag = 0.
[    7.772203] ctp_fetch_sysconfig_para: exchange_x_y_flag = 0.
[    7.779922] ft5x_ts_init: after fetch_sysconfig_para:  normal_i2c: 0x38. normal_i2c[1]: 0xfffe
[    7.785219] ctp_init_platform_resource: tp_reset request gpio fail!
[    7.790702] ctp_init_platform_resource: No power port feature present.
[    7.792230] ctp_wakeup.
[    7.848058] incomplete xfer (0x20)
[    7.850541] incomplete xfer (0x20)
[    7.852936] incomplete xfer (0x20)
[    7.858881] ctp_detect: Detected chip ft5x_ts at adapter 3, address 0x38
[    7.862260] ====ft5x_ts_probe begin=====.  
[    7.869659] input: ft5x_ts as /devices/platform/sunxi-i2c.3/i2c-3/3-0038/input/input2
[    7.874563] ctp_set_irq_mode: config gpio to int mode.
[    7.880419] ctp_set_irq_mode, 225: gpio_int_info, port = 8, port_num = 9.
[    7.882413]  INTERRUPT CONFIG
[    7.885093] ==ft5x_ts_probe over =
[    7.952858] UMP<2>: Inserting UMP device driver. Compiled: Dec  8 2014, time: 18:20:44
[    7.959953] UMP<2>: Using OS memory backend, allocation limit: 134217728
[    7.966491] UMP: UMP device driver  loaded

Here is a non Working Dmesg:
[   12.440073] ===========================ft5x_ts_init=====================
[   12.448854] ctp_fetch_sysconfig_para.
[   12.458318] ctp_fetch_sysconfig_para: after: ctp_twi_addr is 0x38, dirty_addr_buf: 0x38. dirty_addr_buf[1]: 0xfffe
[   12.462528] ctp_fetch_sysconfig_para: ctp_twi_id is 3.
[   12.466970] ctp_fetch_sysconfig_para: screen_max_x = 800.
[   12.471412] ctp_fetch_sysconfig_para: screen_max_y = 480.
[   12.475799] ctp_fetch_sysconfig_para: revert_x_flag = 0.
[   12.480155] ctp_fetch_sysconfig_para: revert_y_flag = 0.
[   12.484872] ctp_fetch_sysconfig_para: exchange_x_y_flag = 0.
[   12.492520] ft5x_ts_init: after fetch_sysconfig_para:  normal_i2c: 0x38. normal_i2c[1]: 0xfffe
[   12.497804] ctp_init_platform_resource: tp_reset request gpio fail!
[   12.503288] ctp_init_platform_resource: No power port feature present.
[   12.504799] ctp_wakeup.
[   12.554332] incomplete xfer (0x20)
[   12.556726] incomplete xfer (0x20)
[   12.559093] incomplete xfer (0x20)
[   12.561516] incomplete xfer (0x20)
[   12.608238] UMP<2>: Inserting UMP device driver. Compiled: Dec  8 2014, time: 18:20:44
[   12.615238] UMP<2>: Using OS memory backend, allocation limit: 134217728
[   12.620428] UMP: UMP device driver  loaded

here is a excerpt from the fex fil regarding ctp:


[ctp_para]
ctp_used = 1
ctp_name = "ft5x_ts"
ctp_twi_id = 3
ctp_twi_addr = 0x38
ctp_screen_max_x = 800
ctp_screen_max_y = 480
ctp_revert_x_flag = 0
ctp_revert_y_flag = 0
ctp_exchange_x_y_flag = 0
ctp_firm = 1
ctp_int_port = port:PH09<6><default><default><default>
ctp_wakeup = port:PH07<1><default><default><1>
ctp_io_port = port:PH09<0><default><default><default>

[ctp_list_para]
ctp_det_used = 1
ft5x_ts = 1
gt82x = 0
gslX680 = 0
gt9xx_ts = 0
gt811 = 0


Not sure if it's related but could you check the scaling_min_freq for your cpu governor.

I remember there was a thread related to i2c device detection errors because of a rather low cpu frequency.

And does removing and reinserting the ft5x module solve the problem when it's not detected,or is a hardware reset the only option?

Not sure if it's related but could you check the scaling_min_freq for your cpu governor.

I remember there was a thread related to i2c device detection errors because of a rather low cpu frequency.

And does removing and reinserting the ft5x module solve the problem when it's not detected,or is a hardware reset the only option?

I have been unable to get the screen working from unloading / re-loading the module.

I have not tried the scaling_min_freq,

But did find this regarding the driver.
https://github.com/Bananian/linu ... 3136eb4db9ba9f16271

It was fixed in Bananian 15.04

Which os and kernel are you on?

I'm actually on an old raspbian release Dec 2014.  which would have been before that fix. Ever since I found that I've been configuring a bananian install with xorg for my python-qt4 gui. Its not ready yet, So I'm re-compiling kernel drivers and trying a new set of modules for the ft5x on the raspbian. Sooner or later I'll get the Bananian up to date to support the software.

Ok, I re-compiled the kernel. Added new updated  /lib/modules + New uImage. Kept exact same Fex file. With the driver mod in the ft5x_ts.c correction to sleep(100ms) After i2C init.. Its working quite well now.

You have to log in before you can reply Login | Sign Up

Points Rules