kodeOS internals

Production test

The rows that check every part of a finished Kode Dot: the fixture, what each row judges, how the E5 final test runs them and how to read a result.

What it is

The production test checks every part of a finished Kode Dot, one row per part, one row at a time. At the factory the final test is test component=all, the E5 test: a station's computer starts it over the cable, and the Kode Dot runs thirteen of the rows, adds a camera's check of the glass and the LED and an operator's presses and touches, and the computer decides whether the unit ships (sdk/kaos/test-dot, internals/e5-wire-contract). Every row also runs by name, and test component=main runs the six that a bare main PCB answers.

A row is an entry in the table TESTS[] in components/kaos/autotest/src/autotest_ao.c, or in the table of the owner that judges it. The Active Object that owns the part judges its row. AO_Autotest walks the table for a group or a name, and AO_TestDot asks it for one row at a time in the E5 run. sdk/kaos/autotest has the design. This page is for the person who tests units on the line and for the engineer who changes a row.

How it is connected

flowchart LR
console["test component=main<br/>or a row"] --> ao["AO_Autotest"]
e5["test component=all"] --> td["AO_TestDot"]
td -- "one row at a time" --> ao
ao -- "asks the owner" --> owner["owner AO<br/>AO_Power, AO_Imu, ..."]
owner -- "TEST_RESULT_SIG" --> ao
ao -- "AUTOTEST_ROW_SIG" --> out["AO_Console<br/>or AO_TestDot"]
out --> reply["test=NAME<br/>result=pass, fail or timeout"]
class console,e5,reply ext
class ao,td,owner,out ao

A row has two independent flags:

• TEST_SYNC rows are judged on AO_Autotest's own thread and publish at once (screenshot, jpeg, clocks, mem, boot, apps, kfw, id, ble_console).
• TEST_ASYNC rows belong to another Active Object, which answers later with TEST_RESULT_SIG, or TEST_SKIP_SIG when what the row needs is not there.

The rows clocks, psram and mem have no owner Active Object:

• clocks is judged by the clocks driver.
• psram is walked by AO_Autotest in steps with the patterns of autotest_psram.c.
• mem reads the two numbers khal_system keeps about internal RAM.

An asynchronous row has a budget, the worst case of its script, held in kqp_config.h. The budget becomes the console's watchdog while the answer is owed. A row still silent after it prints result=timeout and the run goes on, so one owner that hangs cannot stop the count of the others.

Specifications

The command

From a computer: python3 tools/kcli.py -p PORT --settle 5 -v cmd --timeout 600 "test component=main". The default wait is 5 s, so --timeout 600 is needed for a long run. Over Bluetooth use kble.py. See internals/bench-tools.

Each row prints its readings as ! log lines, then one record >|test=NAME result=pass|fail|timeout. A run of a group or a row ends with >|summary pass=N fail=N timeout=N (a skipped=N field appears only when a row was skipped) and >ok. fail= counts every row that did not pass, timeouts included. When fewer rows answered than were promised, the run ends with an error instead of >ok.

The E5 run prints no summary. Each row ends in >|test=NAME result=<word> ms=N, with the word pass, fail, timeout or skipped, or absent or busy when the sequencer would not take it. The station's computer counts them and decides the verdict.

The fixture

Without an item, the row that needs it fails or ends in timeout.

The rows

The groups below put chips and crystals first, then the card and the radio, then the rows that make noise, then the four that need an operator, and the memory rows last, because mem judges what every row before it did to internal RAM.

The E5 run takes its own order. sd and imu run first, while the unit is still, and then the camera part. The rows after it run beside the operator, in this order: audio, haptic, mag, pmic, gauge, ioexp, clocks, ir, nfc, rfid and mem. The run does not take c5, which the station's radio check covers, nor psram, which stays a row of its own.

Rows: chips and crystals

The power chips, the expander, the crystal, the motion parts and the haptic driver.

Rows: the card and the radio

The microSD slot and the C5.

Rows: infrared, NFC, 125 kHz and audio

The rows that send or make noise.

Rows: operator

The four rows judged by a person at the unit.

Rows: memory

The last two rows, which test the PSRAM and the internal RAM.

Rows that no group runs: screenshot, jpeg, fs, boot, apps, kfw, id, ble_console, net, and the user-profile rows sd_user, c5_user, nfc_field, rfid_field, power_plug, nfc_card, rfid_card. They run by name, as every other row does. ble_console needs the BLE console build, net needs the network, and the c5 rows need the radio. sd_verify is a separate verb that judges the card itself and wipes it; the sd row leaves the card as it found it.

Gotchas

Example code

Run the rows on a unit on the bench. The E5 run needs the station and its computer, and internals/e5-wire-contract has its example.

1. Fit the battery, plug in a USB adapter, put a microSD card in the slot, an NFC tag on the reader and an EM4100 tag on the 125 kHz antenna.
2. Run python3 tools/kcli.py -p PORT --settle 5 -v cmd --timeout 600 "test component=sd". The row prints ! readings and one >|test=sd result=pass record, then the summary and >ok.
3. Run the rows that need hands one at a time: test component=buttons, test component=led, test component=display, test component=tp. Press the named button, then TOP for yes and BOT for no on the colours and fields, then tap the two targets.
4. Run test component=mem last. >|summary pass=1 fail=0 timeout=0 and >ok mean the internal pool held its floor.
5. For a main PCB with no panel, card or tags, run test component=main. It ends with its own summary and needs nobody at the glass.

In the SDK

• components/kaos/autotest: AO_Autotest, the table of rows and the PSRAM walk.
• kqp_config.h: the budgets and constants of every row.
• components/kaos/console: the test verb and the records it prints.
• components/kaos/test_dot: AO_TestDot, which runs test component=all.