Mechanism Developers Guide

Mechanism Developers Guide#

Introduction#

Fuze™ Test supports DUT-bound parameterization for external control and acquisition “mechanisms”. These mechanisms can be any external peripheral or device whose control can be wrapped by a parameterized script. This parameterization allows mechanism and peripheral control scripts to remain generic at design time, but instantiated concretely with DUT specific values at execution time.

Mechanism and peripheral control parameterization is achieved through DUT-bound key:value pairs in the DUT’s configuration. This allows a logical key name to be used in DUT preparation algorithm and test case steps referencing the mechanism control script generically. When the step is executed on a particular DUT, the DUT’s value for that key is used to execute the mechanism control script.

This guide describes how to use this feature to integrate your domain-specific external peripheral and mechanism control.

This feature can also be configured at a Resources file (DUT Farm) level if the same value is valid for all DUTs in a particular location.

Core Interface#

There are two levels at which a Resources configuration file can use this feature:

  • At a Resources configuration’s global (DUT Farm) level

  • At a per DUT level

The following example Resources configuration illustrates both of these using the macro_subs field.

{
    "rps": { "list": [] },

    "macro_subs": { "__FARM_SHARED_MECHANISM_IP__": "192.168.0.20" },

    "dut": {
        "list": [
            {
                "id": 1, "rps": 0, "type": "demo-rpi4-arm64", "name": "DEMO-RPI4-ARM64-1", "port": 0,
                "components": {},
                "remote": {
                    "uri": "192.168.0.40",
                    "dir": "/home/user1/WS",
                    "usr": "user1",
                    "pwd": "password1234"
                },
                "macro_subs": { "__DUT_MECH_ID__": "1234567" }
            },
            {
                "id": 2, "rps": 0, "type": "demo-stm32-nucleo-h5", "name": "DEMO-STM32-NUCLEO-H563ZI-1", "port": 0,
                "components": { "mcu": { "type": "sth563", "port": 0 } },
                "remote": {
                        "uri": "192.168.0.41",
                        "dir": "/home/c2latfuser/ATF-WS",
                        "usr": "c2latfuser",
                        "pwd": "password1234"
                },
                "macro_subs": { "__DUT_MECH_ID__": "8675309" }

            }
        ]
    },

    "pathing": { "searchdirs": [ "./testcases", "../../IMAGES" ] },

    "env": "default",
    "tests": "default"
}

Referencing from Test JSON#

Given the above example, the macros can be accessed in a Test Case as follows:

{
    "comment": "Verify DUT and Farm level macros can be used",
    "name": "tc_dut-macro-feature-test",
    "id": "dut-macros-1",
    "testcmds": [
        {
            "type": "tcs",
            "comment": "Control Farm Level Mechanism",
            "cmd": "python3 control-farm-mech.py __FARM_SHARED_MECHANISM_IP__",
            "ret_code": 0,
            "expout": [],
            "failpattern": []
        },
        {
            "type": "tcs",
            "comment": "Control DUT Level Mechanism",
            "cmd": "python3 control-dut-mech.py __DUT_MECH_ID__",
            "ret_code": 0,
            "expout": [],
            "failpattern": []
        }
    ]
}

This example shows how a DUT bound macro can be used when designing a test case without needing to manage the added complication of the DUT upon which it may execute.