11.7. ETHFW Status/Heartbeat

11.7.1. Introduction

In PSDK QNX 10.0, support was added for the io-pkt CPSW5/9G thin client to get and report the ETHFW server status from a heartbeat task. The default heartbeat polling period is 1000 ms.

By default the status, if not normal will print the status to the slog which serves well for debugging purposes.

11.7.2. Customization

If desired, the thin client driver can be modified to take action depending on the ETHFW status returned by the heartbeat. Inside ${PSDK_QNX_PATH}/qnx/devnp/src/enetlld_if.c is where the ETHFW status gets sent to slog. It is TI’s recommendation that the below code be modified depending on the desired usecase. The section where the status is logged is shown below:

#if defined (CPSW9G) || defined (CPSW5G)
static void EnetIf_hbStatus(EthRemoteCfg_ServerStatus serverStatus,
                            void *cbArg)
{
    switch (serverStatus)
    {
        case ETHREMOTECFG_SERVERSTATUS_UNINIT:
            EnetIf_print("Server status: server has not been initialized\r\n");
            break;
        case ETHREMOTECFG_SERVERSTATUS_READY:
            EnetIf_print("Server status: server is running normally\r\n");
            break;
        case ETHREMOTECFG_SERVERSTATUS_RECOVERY:
            EnetIf_print("Server status: Ethernet switch is under recovery\r\n");
            break;
        case ETHREMOTECFG_SERVERSTATUS_BAD:
            EnetIf_print("Server status: Not responding, possibly in bad/crashed state\r\n");
            break;
        default:
            EnetIf_print("Server status: Unexpected status: %d\r\n", (int32_t)serverStatus);
            break;
    }
}
#endif

If interface level actions are desired from within the driver itself, then io-pkt managed threads must make that change and some sort of a signal (pulse or message) should be used to communicate the status to said thread. For an example of this in the io-pkt thin client driver, see the cpsw_recovery_thread() task in ${PSDK_QNX_PATH}/qnx/devnp/ethremotecfg/client/src/cpsw_proxy.c. For more information of io-pkt managed threads, please see the QNX io-pkt threading documentation.

If action is desired from an external process, then some form of QNX InterProcess Communication (IPC) is recommended.