This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3120BOOST: sl_Start - sync pattern not found

Part Number: CC3120BOOST
Other Parts Discussed in Thread: CC3120

I'm porting the simple link driver to an nRF52840 MCU for our product.  I have connected an CC3120BOOST to an nRF52840-Preview-DK to test out the driver.  The CC3120BOOT is fresh out of the box with nothing done to it other than connecting it to the nRF52840 dev board.  The signals that are connected are:

P0.03 to nHIB

P0.04 to IRQ

P0.28 to SPI_CS

P0.29 to SPI_MOSI

P0.30 to SPI_CLK

P0.31 to SPI_MISO

After calling sl_Start it appears that the nHIB is being toggled correctly, and IRQ changes in response, then the Wi-Fi library tries to find a sync pattern in the SPI reads - but this fails.  The sequence I'm seeing over SPI is:

Host -> CC3120 : 65 87 78 56

Host <- CC3120 : FF FF FF FF FF FF FF FF

Host <- CC3120 : FF FF FF FF 00 00 00 00

Host <- CC3120 : 00 00 00 00 00 00 00 00

This repeats until a timeout occurs.

From looking at the code it appears the response that is expected is something like

Host <- CC3120 : BA DC CD AB — — — —

Any ideas on why I'm not seeing a sequence of 12 0xFF bytes and then all 0x00 bytes, rather than the expected result?

  • Hi,

    Should be very straight forward.

    Does IRQ line get de-asserted when the cc3120 gets "65 87 78 56" sync pattern?


  • The IRQ line is not immediately de-asserted.  It is de-asserted about 90 ms later.

  • It looks like it is taking about 80ms from nHIB high to IRQ going high.  The data sheets says 50ms.   But also says "If temperature changes by more than 20°C, initialization time from HIB can increase by 200ms due to radio calibration."  That isn't my case.  In my code I've added a delay of 50ms followed by a loop that checks for IRQ being low and if so waits for up to 200ms more.  This seems to work as after 80ms IRQ goes high and then I get the expected response over SPI.  Am I reading the data sheet incorrectly?  Should this be happening in under 50ms?

  • It looks like I'm getting a good response from the device now.  However, when the sl_Start complete callback is made it looks like the driver has not put the device into the started state yet, so I can't make any further API calls.  Any idea why that is?  Shouldn't the driver state already be "started" before invoking my callback?

    Here is my code:

    void SimpleLinkInitCallback(_u32 mode, SlDeviceInitInfo_t *deviceInitInfo) { wt_assert(deviceInitInfo->ChipId == 0x30000000); SlDeviceVersion_t version; _u16 pConfigLen = sizeof(version); _u8 pConfigOpt = SL_DEVICE_GENERAL_VERSION; _i16 status = sl_DeviceGet(SL_DEVICE_GENERAL, &pConfigOpt, &pConfigLen, (_u8 *)(&version)); wt_simplelink_assert(status); // status is -2018 SL_RET_CODE_DEV_NOT_STARTED } void main(void) { wt_simplelink_initialize(); int status = sl_Start(NULL, NULL, SimpleLinkInitCallback); wt_simplelink_assert(status); while (true) { sl_Task(0); } }

    And here is the device.c handler in the API that looks like it calls my callback and only after that sets the device state to started:

    _SlReturnVal_t _SlDeviceHandleAsync_InitComplete(void *pVoidBuf)
        InitComplete_t     *pMsgArgs = (InitComplete_t *)_SL_RESP_ARGS_START(
        SlDeviceInitInfo_t DeviceInitInfo;
            DeviceInitInfo.ChipId = pMsgArgs->ChipId;
            DeviceInitInfo.MoreData = pMsgArgs->MoreData;
                                     pMsgArgs->Status), &DeviceInitInfo);
                g_pCB->ObjPool[g_pCB->FunctionParams.AsyncExt.ActionIndex].pRespArgs, pMsgArgs,
  • I also tried calling sl_Start(NULL, NULL, NULL) which is supposed to return after starting.  However it just adds a spawn entry, but never executes it.   So sl_Start hangs and does not return.

    I'm using nonos.

  • Hi,

    It is different whether you use a callback or not when referring to the SL_SET_DEVICE_STARTED.

    With the callback it is implemented after the callback is called and with no callback, it is implemented in the sl_Start() itself.

    Anyway, let's stick with no callback for a start and see what happens.

    sl_Start() is pending on a signal with a 64 seconds timeout. Do you get this signal?

    Is the _SlDeviceHandleAsync_InitComplete() invoked? if it does, then it signals via SL_DRV_SYNC_OBJ_SIGNAL() and should trigger the signal waited by sl_Start().

    In this case you should also get the return value of starting the device via the return value of sl_Start(). what do you get?


  • Here is the call stack after calling sl_Start, to showing where it is hanging:


    sl_Start(0, 0, 0)




    There is an interrupt processed which leads to this call stack:


    sl_Start(0, 0, 0)








    The _SiNonOsSpawn function puts an entry into g__SlNonOsCB and then returns.

    Because this is a non-os configuration, that entry is never run because the main/only thread is still executing sl_Start.  It seems like _SlDrvRxIrqHandler should not be queuing an entry, but instead should be calling sl_SyncObjSignalFromIRQ?

  • Hi,

    What SDK are you using?

    Basically, sl_start() creates a command sync object at the beginning of the function.

    In user.h header file it is defined to SemaphoreP_create_handle.

    The semaphore callback is set to tiDriverSpawnCallback() which calls the _SlNonOsHandleSpawnTask() which should free you on the signal that sl_Start() is waiting for.

    Can you check it?