RTOS/CC1310: CC1310 sleep problems

What is crossed out in the diagram is now absent on the board. In general, when creating the board, I was guided by the reference design from the TI website.

To make it clear what we are measuring, I attached a photo of a multimeter, which shows in which mode it is located. In one case, we see 1., and in the other 0.020 (while the multimeter emits a signal, indicating the closure of these contacts).

6177.CC1310_LAUNCHXL.h

I tried to set all contacts to PIN_UNASSIGNED

I apologize. Forgot to attach this file in the past message.

8741.Board.h

Yes, we tried to measure with another multimeter and a laboratory power supply that shows current consumption. The result is the same everywhere. We also have a launchpad, and its performance is normal (8-10 µA, this is probably due to the flash drive installed on this board).

But we are faced with another problem, which is possible and sleep well. It consists in the following:
If we take the pinstandby project for the CC1310 LaunchPad, and change it for a 4x4 chip (in the CC1310_LAUNCHXL.h file, we set unused contacts to PIN_UNASSIGNED). After that we remove the LEDs from on and off from the main code, and instead we switch the legs (for example, IOID_9), while the dream remains (the sleep function), we see the following situation - If we select XOSC or RCOSC as the LF clock in the ccfg.h file, we see the IOID_9 contact jump, but if we select "LF clock derived from High Frequency XOSC" as the clock, then everything works as expected. I can understand that XOSC may not work due to a faulty external crystal, but that’s why the program doesn’t work with RCOSC, is it an internal crystal? We soldered the external crystal at 32 kHz, but this did not solve the problem and RCOSC did not work. How can this behavior be explained? The same code was tested on other examples from CCS (TI / RTOS examples) - the result is the same. Although we do not see the switching of the contact, the chip still goes to sleep with a consumption of 100 μA, but this is not the ideal behavior.

I would also like to clarify that on the oscilloscope when using XOSC we see a sine wave, exactly the same as on the CC1310 Launchpad. Just in case, I attach the main code in which we made the above changes.

#include <unistd.h>

/* Driver Header files */
#include <ti/drivers/PIN.h>
#include <ti/drivers/pin/PINCC26XX.h>

/* Example/Board Header files */
#include "Board.h"

/* Led pin table */
PIN_Config LedPinTable[] =
{
    IOID_9    | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,
    PIN_TERMINATE
};

void *mainThread(void *arg0)
{
    PIN_State   pinState;
    PIN_Handle  hPin;
    uint32_t    standbyDuration = 5;
    uint32_t currVal = 0;

    /* Allocate LED pins */
    hPin = PIN_open(&pinState, LedPinTable);

    /*
     * Repeatedly sleeps for a duration, to allow repeated entry/exit
     * from standby. The LED states are toggled on each iteration
     */
    while(1) {
        /* Sleep, to let the power policy transition the device to standby */
        sleep(standbyDuration);
        currVal =  PIN_getOutputValue(IOID_9);
        PIN_setOutputValue(hPin, IOID_9, !currVal);
    }
}

A couple of questions: what do you mean by "the dream remains"? You have used the word dream also before and not sure what you mean.

Are you able to comment on the estimated sale volume for this product?

Back to my problem. Below I attached a picture. It shows the sine wave from crystal at 32 kHz. An empty gap (hole, pit, and so on) appears as soon as I try to call the Task_sleep () function. If in the code written above (in the previous message) to comment out the call to this function, then the sine wave goes without interruption. Apparently, due to this gap, the chip cannot go to sleep and therefore I see a strange program execution (the IOID_9 leg does not switch every 5 seconds). This behavior occurs when using an internal LF crystal (LF RCOSC), and when using an external (LF XOSC). I replace the crystal in the ccfg.h file (#ifndef SET_CCFG_MODE_CONF_SCLK_LF_OPTION)