CC2652R7: Sensor Controller files that work on tirtos7 when ported to TI-Matter lock-app no longer work.

Part Number: CC2652R7
Other Parts Discussed in Thread: SYSBIOS

Summary:
We now have a TI-Matter lock-app that builds with Sensor Controller files integrated in. However, during system boot the initialization calls related to the Sensor Controller lock up the system. Our hunch is that it seems to be related to the Ready and Event interrupts and almost gives the sense that a flurry of non-stop interrupts are consuming the system’s bandwidth.

I notice in our working tirtos7 system that the *.syscfg file generates a ti_sysbios_config.c file with the following logic:

void Startup_exec()
{
    /* Startup first functions */
    Hwi_initNVIC();
    Hwi_initStack();
    BIOS_init();
    ti_sysbios_family_arm_cc26xx_TimestampProvider_init();

    /* Module init functions */
    System_init();
    Clock_init();
    Swi_init();
    Task_init();
    Idle_init();
    Hwi_init();

    Startup_done = true;
}

… and yet the processing of the TI-Matter chip.syscfg does not appear to be generating a similar sort of routine. In particular, we are left wondering if there are hwiP_ init*() counter parts that we need to add somewhere to replace the Hwi_init*() calls shown above? Details of our problem below.

Details #1:
We have the following collection of files that work in our tirtos7 based system:

scif.c            
scif.h            
scif_framework.h
scif_framework.c
scif_osal_tirtos.h
scif_osal_tirtos.c

We are interested in taking this working collection and integrating it into the TI-Matter lock-app. Along the way we learned that the scif_osal_tirtos.c requires hand modification when bringing it into the TI-Matter lock-app. In particular we manually transitioned its dependence on functionality described by:

#include <ti/sysbios/knl/Semaphore.h>
#include <ti/sysbios/family/arm/m3/Hwi.h> semaphore.h

…to the like functionality described by this instead:

#include "FreeRTOS.h"
#include "semphr.h"
#include <ti/drivers/dpl/HwiP.h>

Details #2:
The boot lock-up appears in the block of MCU code that starts up the Sensor Controller. This is the same block that we have been using successfully with our tirtos7 system:

static void SetupTheSensorController()
{
    scifOsalRegisterCtrlReadyCallback(scCtrlReadyCallback);
    scifOsalRegisterTaskAlertCallback(scTaskAlertCallback);
    scifInit(&scifDriverSetup);   <—— Unfortunately, this call never returns, not sure why????
    …
    <snip lines here not related to this conversation>
    …
    scifStartTasksNbl(BV(SCIF_ADC_DATA_LOGGER_TASK_ID));
}

Details #3:
As we look at the internal implementation of scifInit() — the call that never returns — it is a block of code that was auto-derived by the Sensor Controller development tools and through experimenting we notice that commenting out two lines within that routine allow the TI-Matter Lock-app to boot (albeit with a non working Sensor Controller). Here are the two lines we commented out (search for “TODO”):

File: scif_framework.c
Routine:
SCIF_RESULT_T scifInit(const SCIF_DATA_T* pScifDriverSetup) {

    // Perform sanity checks: The Sensor Controller cannot already be active
    if (HWREG(AUX_SCE_BASE + AUX_SCE_O_CTL) & AUX_SCE_CTL_CLK_EN_M) {
        return SCIF_ILLEGAL_OPERATION;
    }

    // Copy the driver setup
    memcpy(&scifData, pScifDriverSetup, sizeof(SCIF_DATA_T));

    // Reset wake-up event sources and flags, and setup the Sensor Controller vector table
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_WUGATE) = 0;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_PROGWU0CFG) = 0x0000;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_PROGWU1CFG) = 0x0000;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_PROGWU2CFG) = 0x0000;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_PROGWU3CFG) = 0x0000;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_WUFLAGSCLR) = 0x00FF;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_WUFLAGSCLR) = 0x0000;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_VECCFG0) = AUX_SYSIF_VECCFG0_VEC_EV_SW_WU0;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_VECCFG1) = AUX_SYSIF_VECCFG5_VEC_EV_SW_WU1;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_VECCFG2) = AUX_SYSIF_VECCFG1_VEC_EV_PROG_WU0;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_VECCFG3) = AUX_SYSIF_VECCFG2_VEC_EV_PROG_WU1;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_VECCFG4) = AUX_SYSIF_VECCFG3_VEC_EV_PROG_WU2;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_VECCFG5) = AUX_SYSIF_VECCFG4_VEC_EV_PROG_WU3;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_VECCFG6) = AUX_SYSIF_VECCFG6_VEC_EV_SW_WU2;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_VECCFG7) = AUX_SYSIF_VECCFG7_VEC_EV_NONE;
    HWREG(AUX_SYSIF_BASE + AUX_SYSIF_O_WUGATE) = 1;

    // Upload the AUX RAM image
    memcpy((void*) AUX_RAM_BASE, scifData.pAuxRamImage, scifData.auxRamImageSize);

    // Select SW_WU0 as reset vector
    HWREG(AUX_SCE_BASE + AUX_SCE_O_CTL) = 0 << AUX_SCE_CTL_RESET_VECTOR_S;

    // Perform driver setup specific initialization
    scifData.fptrDriverSetupInit();

    // Set the READY event (to the MCU domain)
    HWREG(AUX_EVCTL_BASE + AUX_EVCTL_O_SWEVSET) = AUX_EVCTL_SWEVSET_SWEV0_M;

    // The System CPU shall wake up on the ALERT event
    scifSetMcuwusel(OSAL_TASK_ALERT_MCUWUSEL_WU_EV_INDEX, AON_EVENT_MCUWUSEL_WU0_EV_AUX_SWEV1);

    // Start the Sensor Controller
    HWREG(AUX_SCE_BASE + AUX_SCE_O_CTL) |= AUX_SCE_CTL_CLK_EN_M;

    // Register, clear and enable the interrupts
    osalRegisterCtrlReadyInt();
    osalClearCtrlReadyInt();
#if 0 /* TODO: 0 == temp experiment to allow full boot. */
    osalEnableCtrlReadyInt();
#endif
    osalRegisterTaskAlertInt();
    osalClearTaskAlertInt();
#if 0 /* TODO: 0 == temp experiment to allow full boot. */
    scifOsalEnableTaskAlertInt();
#endif

    return SCIF_SUCCESS;

} // scifInit

Summary:
We feel like we are stalled in our attempts to bring up a modified TI-Matter Lock-app. Everything we’ve done related to MCU work has been fine and the one last remaining item is getting the Sensor Controller portion of our system working. Again, we have it all working within the tirtos7 system. Any ideas?

Thanks in advance!
Steve K.