XO 4 Touch Testing: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
No edit summary
Line 32: Line 32:
''After testing is complete, the MSP430 should probably be placed into reset to allow for cable disconnect. It should be rebooted for each test.''
''After testing is complete, the MSP430 should probably be placed into reset to allow for cable disconnect. It should be rebooted for each test.''


* can be done now with revision A IR PCBA if the finger or stylus is omitted:
* can be done now with revision A IR PCB if the finger or stylus is omitted:
select /touchscreen
select /touchscreen
0 to faults test-fss
0 to faults test-fss
Line 39: Line 39:
key drop
key drop


* waiting on revision B IR PCBA for implementation:
* waiting on revision B IR PCB for implementation:
select /touchscreen
select /touchscreen
0 to faults test-edges
0 to faults test-edges \ not yet implemented
faults if green-screen else red-screen then
faults if green-screen else red-screen then
touch-rst-gpio# gpio-clr
touch-rst-gpio# gpio-clr
Line 53: Line 53:
There should be no operator interaction with the "known good" IR PCB. The operator should be able to drop a motherboard into
There should be no operator interaction with the "known good" IR PCB. The operator should be able to drop a motherboard into
the test fixture and power it on --starting the automatic test menu. When run the touchscreen test shall attempt to install firmware into the microcontroller, then attempt to communicate with the "known good" IR PCB. The test result should be indicated visually and the automated test stopped on failure.
the test fixture and power it on --starting the automatic test menu. When run the touchscreen test shall attempt to install firmware into the microcontroller, then attempt to communicate with the "known good" IR PCB. The test result should be indicated visually and the automated test stopped on failure.

* checking for proper functioning of the touchscreen microcontroller and connector to the IR PCB can be achieved with:
test /touchscreen
* firmware can be flashed using:
" u:\zforce.hex" $flash-bsl
* is it safe to repeatedly flash firmware into the microcontroller?
* the time taken to flash firmware can be quite long, should this be done at this test stage?


==MB ASSY==
==MB ASSY==
Line 60: Line 67:


The operator will power the laptop on --starting the automatic test menu. When run, the touchscreen test shall establish communications with the microcontroller. Then it should wait for the operator to run their finger/stylus along two adjacent edges of the light guide. The test result should be indicated visually and the automated test stopped on failure. If no operator input is detected in a fixed amount of time (thirty seconds), the test should be stopped indicating failure.
The operator will power the laptop on --starting the automatic test menu. When run, the touchscreen test shall establish communications with the microcontroller. Then it should wait for the operator to run their finger/stylus along two adjacent edges of the light guide. The test result should be indicated visually and the automated test stopped on failure. If no operator input is detected in a fixed amount of time (thirty seconds), the test should be stopped indicating failure.

* waiting on revision B IR PCB for implementation:
test /touchscreen


==Lightguide Tooling==
==Lightguide Tooling==
Line 67: Line 77:


They should simply be able to attach a bezel assembly to the motherboard, and press a button on the keyboard. No interaction with the lightguide is required during the testing. Upon completion, the screen indicates pass or fail, but also provides numbers reporting the performance of the different optical paths.
They should simply be able to attach a bezel assembly to the motherboard, and press a button on the keyboard. No interaction with the lightguide is required during the testing. Upon completion, the screen indicates pass or fail, but also provides numbers reporting the performance of the different optical paths.

diag-mode test /touchscreen \ gives pass fail


==Sampled QA==
==Sampled QA==

Revision as of 05:59, 28 August 2012

  This page is monitored by the OLPC team.

This page describes the production test support provided with the touchscreen in XO-4.

Test routines are provided in Open Firmware for testing the various components of the touchscreen system, at various stages of manufacture. The touchscreen system consists of a microcontroller on the motherboard, an IR PCB which contains the IR transmitters and receivers, a flat flexible cable interconnecting the two, and a plastic lightguide which collimates the light to/from the LED sensors.

IR PCB SMT

This test is done to bare IR PCB boards, without a light guide. The code runs on XO-4 A2 or later motherboards.

The idea is to check for opens and shorts of the IR diodes and detectors, as well as proper mounting of the ASIC and connector on the IR PCB.

There should be no operator interaction with the IR PCB. They should simply be able to drop a board into the test fixture, press a button on the keyboard, and the screen says pass or fail with an appropriate background (red/green).

After testing is complete, the MSP430 should probably be placed into reset to allow for cable disconnect. It should be rebooted for each test.

select /touchscreen
0 to faults  test-os
faults  if  green-screen  else  red-screen  then
touch-rst-gpio# gpio-clr
key drop

IR PCB ASSY

This test is done to IR PCB assemblies, including a light guide and bezel. The code runs on XO-4 A2 or later motherboards in a production line situation, using a test fixture to connect to the bezel assembly.

The idea is to check for proper assembly of the lightguide and IR PCB, as well as proper lightguide and IR PCB operation.

They should simply be able to drop a bezel assembly into the test fixture, and press a button on the keyboard. They then need to pass a finger or stylus along two adjacent inside edges of the bezel to complete the test. Upon completion, the screen says pass or fail with an appropriate background (red/green). There should be an automatic abort of the test (w. fail) if the appropriate motion isn't detected within thirty seconds.

After testing is complete, the MSP430 should probably be placed into reset to allow for cable disconnect. It should be rebooted for each test.

  • can be done now with revision A IR PCB if the finger or stylus is omitted:
select /touchscreen
0 to faults  test-fss
faults  if  green-screen  else  red-screen  then
touch-rst-gpio# gpio-clr
key drop
  • waiting on revision B IR PCB for implementation:
select /touchscreen
0 to faults  test-edges  \ not yet implemented
faults  if  green-screen  else  red-screen  then
touch-rst-gpio# gpio-clr
key drop

MB SMT

This test is done to each bare laptop motherboards as part of SMT testing (TS code SMT). The code runs on XO-4 A2 or later motherboards.

The idea is to check for proper functioning of the touchscreen microcontroller and connector to the IR PCB.

There should be no operator interaction with the "known good" IR PCB. The operator should be able to drop a motherboard into the test fixture and power it on --starting the automatic test menu. When run the touchscreen test shall attempt to install firmware into the microcontroller, then attempt to communicate with the "known good" IR PCB. The test result should be indicated visually and the automated test stopped on failure.

  • checking for proper functioning of the touchscreen microcontroller and connector to the IR PCB can be achieved with:
test /touchscreen
  • firmware can be flashed using:
" u:\zforce.hex" $flash-bsl
  • is it safe to repeatedly flash firmware into the microcontroller?
  • the time taken to flash firmware can be quite long, should this be done at this test stage?

MB ASSY

This test is done to each assembled laptop as part of assembly testing (TS code ASSY). The code runs on XO-4 A2 or later motherboards.

The idea is to check for proper functioning of the touchscreen microcontroller, IR PCB/lightguide assembly, and the connection between the two.

The operator will power the laptop on --starting the automatic test menu. When run, the touchscreen test shall establish communications with the microcontroller. Then it should wait for the operator to run their finger/stylus along two adjacent edges of the light guide. The test result should be indicated visually and the automated test stopped on failure. If no operator input is detected in a fixed amount of time (thirty seconds), the test should be stopped indicating failure.

  • waiting on revision B IR PCB for implementation:
test /touchscreen

Lightguide Tooling

This test is done to light guides, mainly during tooling development, but also for quality control once production has started. The code runs on XO-4 A2 or later motherboards in a production line situation.

The idea is to check for proper operation of the lightguide, using a known good IR PCB.

They should simply be able to attach a bezel assembly to the motherboard, and press a button on the keyboard. No interaction with the lightguide is required during the testing. Upon completion, the screen indicates pass or fail, but also provides numbers reporting the performance of the different optical paths.

diag-mode test /touchscreen \ gives pass fail

Sampled QA

This test is done to assembled laptops for quality control once production has started. The code runs on XO-4 A2 or later motherboards .

The idea is to check for proper operation of the touchscreen, including specific light guide performance.

They will have to power the unit up to Open Firmware, then manually execute two or more tests:

  • The lightguide quality test, printing out the perceived performance of the lightguide
  • A linearity test, where they use a straight edge and a stylus, and the "max error" is computed

Field Repair

This test is done to units suspected of having a problem with their touchcreen:

test /touchscreen

If a problem is found which can be traced to a particular component (IR diode, IR LED, or connector), it should be clearly identified.