Opened 4 years ago

Closed 4 years ago

Last modified 20 months ago

#12391 closed enhancement (fixed)

non-touchscreen SKU support

Reported by: Quozl Owned by: Quozl
Priority: normal Milestone:
Component: ofw - open firmware Version: Development firmware
Keywords: Cc: pgf
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no


The TOUCH_HD# pin is to be:

  • pulled high on a touchscreen SKU (as already occurs),
  • pulled low on a non-touchscreen SKU.

When low, opening the touchscreen device shall fail with no touchscreen expected.

Change History (15)

comment:1 Changed 4 years ago by Quozl

  • Action Needed changed from design to add to build

Fixed in svn 3493 and git 95d0d2ce.

comment:2 Changed 4 years ago by pgf

i missed this conversation. is this a repurposing of TOUCH_HD? before, i thought it was "if high, tri-state all touchscreen gpios", which wasn't implemented in the linux driver. now it simply means the controller is populated?

comment:3 Changed 4 years ago by Quozl

  • Cc pgf added

thanks, good point.

no, TOUCH_HD# is an inverted signal, active low, and is an input to SoC, so the correct semantics are "if low, tri-state all touchscreen gpios". this is from page 3 of zForce_Communication_Interface_4_1.pdf and confirmed by observation on laptops with a touchscreen controller; the signal is high.

what we are doing on non-touchscreen SKU is (a) not populating the microcontroller, and R266, and (b) pulling the TOUCH_HD# signal low by populating R273. (R366 and R273 form the 3.3V to 1.8V level converter for the signal on the way to the SoC).

for the linux driver you might either:

  • check TOUCH_HD# first, and if low, abandon device startup, or
  • defer device startup until TOUCH_HD# goes high.

both will meet the goal of not providing a touchscreen software interface for a laptop that has no touchscreen controller. the latter will allow debugging where TOUCH_HD# is held low on boot. i imagine you would prefer the former.

comment:4 Changed 4 years ago by Quozl

  • Action Needed changed from add to build to review

Is in Q7B09. Waiting for Quanta to confirm fix.

comment:5 Changed 4 years ago by pgf

thanks. a fix (of the "former" style) applied to the zforce linux driver as well. much nicer than an apparent error in the kernel log.

comment:6 Changed 4 years ago by Quozl

U16 is pulling TOUCH_HD# low, but U14 has a default pullup, leaving the voltage undefined. It looks like the signal is not active low after all.

comment:7 Changed 4 years ago by Quozl

Fixed in svn 3502 which:

  • treats the signal as active high, not active low,
  • momentarily enables a SoC pull-down before sampling the pin,
  • works with XO-4 touchscreen SKUs now,
  • is designed to work with XO-4 non-touchscreen SKUs if the BOM is changed to depopulate U16, and keep R267 (3.3V pull-up on controller side of level converter), R266 (level converter high side), and R273 (level converter low side).

comment:8 Changed 4 years ago by pgf

my understanding was that TOUCH_HD# is intended to be an input from the neonode debug connector that tells the SoC to tri-state its drivers, so that the msp430 can be driven from the connector. if that's the case, then we can't simply treat it as active high, unless there's an inversion being done somewhere, and i don't see that.

but as you've observed, the touchscreen controller is pulling the signal low in normal operation. i think that behavior is incorrect, and that it should be an input to the controller. but even if the controller should be driving that pin, it shouldn't be driving it low in normal operation.

comment:9 Changed 4 years ago by Quozl

i agree there is a bit of ambiguity. one of the documents (2012-05-04) says the signal is active low, another later document (2012-06-25) does not say the signal is active low. both documents say the signal _on the microcontroller_ is an indicator to host processor.

i didn't want to ask for the signal to be changed, but i see you have.

if the signal is inverted by neonode in a following release, we will have to deal differently with the existing B1 and C1 population.

if the signal is left as is, we can deal with the issue using a BOM change (populate/depopulate) only.

comment:10 Changed 4 years ago by pgf

why will we have to treat existing B1 and C1 differently, if they change the firmware to not drive that signal low? won't that simply make things work the way we think they should? perhaps i'm hindered by not having access to the non-TS BOM.

comment:11 Changed 4 years ago by Quozl

in that we will have to deal with the population of laptops in the B1 and C1 range that have old touchscreen firmware, which behave with active high TOUCH_HD#.

the B1s can't upgrade touchscreen firmware without losing touchscreen performance, due to the different lightguide.

the C1s can upgrade, but if we treat TOUCH_HD# as active low then we can't do this upgrade automatically.

sure, it is a change that can be managed, but it seems the only reason we want the change is so that it meets neonode's documentation and lets them use their debug connector. we don't really need those two things.

i don't have the BOM either, i'm relying on memory of discussions.

comment:12 Changed 4 years ago by pgf

if a laptop is a B1, we can skip the check entirely. if it's a C1, we can either skip the check, or tell the owner to do a manual firmware upgrade. doesn't seem like a big deal, and it means we're not designing around their bug. i'm tired of designing around vendor bugs. ;-)

comment:13 Changed 4 years ago by Quozl

Skips the test for B1. Breaks automatic upgrade of touchscreen firmware, as agreed.

comment:14 Changed 4 years ago by Quozl

  • Action Needed changed from review to no action
  • Resolution set to fixed
  • Status changed from new to closed

comment:15 Changed 20 months ago by Quozl

  • Milestone 4-firmware deleted

Milestone 4-firmware deleted

Note: See TracTickets for help on using tickets.