• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 39 subscribers
  • Views 224 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC3135: sl_start(0,0,0) is stuck for CC3135 WiFi Chipset

TI-CSC
Genius 11765 points
Part Number: CC3135
Other Parts Discussed in Thread: SYSCONFIG, , UNIFLASH

Hello E2E Experts,

Good day.

I am porting simplelink host driver to STM32 baremetal.

After running sl_start(0,0,0) is stuck, even after receiving the interrupt from the CC3135 module.

Because it is baremetal, I don't have a way to run sl_task()

The code is waiting infinitely on semaphore in sl_start.

Regards,

CSC

  • 0
    TI__Guru 61575 points

    Hi,

    there is a reference with STM (SWRA704). Have you looked into it?

    basically, it is best to probe the SPI lines and interrupt line with a logic to see what we get from the chip when it is switched on.

    Shlomi

  • 0 in reply to Shlomi Itzhak
    TI__Genius 11765 points

    Hello Shlomi,

    Good day.

    The issue is not fully resolved yet.
    I was able to get a response after making sl_start call asynchronous & continuously calling sl_Task(NULL) in a loop as shown below.
     
    void SimpleLinkInitCallback(_u32 status)
    {
        DLOG("Handle SimpleLink Interface acording to ststus %d\n", status);
        gIsInited = 1;
    }
     
    void main()
    {
    *****
    *****
    retVal = sl_Start(NULL, NULL, SimpleLinkInitCallback);
     while(!gIsInited)
      {
        sl_Task(NULL);
       timerMsecWait(1);
      }
    *****
    *****
    }
     
    But, I don't see the above implementation to be clean.
     
    So digging further, I realized that my semaphore implementation was not matching the TI baremetal semaphore implementation,
    Below is the example provided by TI for their semaphore implementation.
    int SemaphoreP_create_handle(SemaphoreP_Handle* pSemHandle)
    {
        SemaphoreP_Params params;

        SemaphoreP_Params_init(&params);

        params.callback = tiDriverSpawnCallback;

        (*(pSemHandle)) = SemaphoreP_create(1, &params);

        if(!(*(pSemHandle)))
        {
            return(-1);
        }

        return(SemaphoreP_OK);
    }
     
    I am not able to understand when & where the callback tiDriverSpawnCallback should be invoked
    Kindly let me know if my direction is right and if so provide details on how the tiDriverSpawnCallback should be invoked.
    Regards,
    CSC
  • 0 in reply to TI-CSC
    TI__Guru 61575 points

    Hi,

    So you are not using any OS?

    The implementation above is for non-OS case. Just to elaborate, in non-OS, SimpleLink host driver architecture mandate calling 'sl_task' in the application's main loop. The purpose of this call, is to handle asynchronous events and get flow control information sent from the NWP.

    The callback is eventually called from the sl_Task() and looks for a spawned entry that is a result of an unsolicited event (like init complete, wlan connected, IP address acquired and so on).

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    TI__Genius 11765 points

    Hello Shlomi,

    Good day.

    I am working on bare metal - STM32 M4 MCU.
    I have a main task form where both sl_start  & sl_task need to be called. As sl_start(0,0,0) blocks, it was not possible to call sl_task.
    It appeared to me that it wasn't a clean solution, to make sl_start asynchronous, but based on your mail, it looks like we don't have any other option.
    Another clarification
    I want to configure the SPI interface to 16-bit or 32-bit mode. How should I go about this? 
    Also are there any tutorials on how to generate firmware for TI's CC3135 wifi chipset?
    Regards,
    CSC
  • 0 in reply to TI-CSC
    TI__Guru 61575 points

    Hi,

    yes, since there is no rtos you must call sl_Task().

    See code snippet from one of the examples.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    status = sl_Start(0,0,0);
    ASSERT_ON_ERROR(status);
    /* waiting for fast connect proccess to compleate */
    sl_Task(NULL);
    while (!IS_IP_ACQUIRED(PowerMeasure_CB.slStatus))
    {
    sl_Task(NULL);
    ;
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The SPI data bits used with CC32xx is 32bits and with an external MCU (STM, MSP) is for some reason 8bits, not sure why it was set to 8.

    What do you mean by generating the firmware? it is called a servicepack and it needs to be loaded to the device. It is signed by TI and provided as part of the SDK.

    Shlomi 

  • 0 in reply to Shlomi Itzhak
    TI__Genius 11765 points

    Hello Shlomi,

    Good day.

    I ended up attaching a callback to sl_start, so it becomes non-blocking and then waits in a while loop for the callback to be triggered. It works for now.
    I was referring to the use of tools (ex. sysconfig tool) to generate images (firmware or configs) that provides a 16-bit SPI interface.
    Can this work? If so, can I know the steps & settings that need to be set in the tool for the CC3135MOD (attached a picture of our custom board using the TI wifi chipset)?
    Regards,
    CSC
  • 0 in reply to TI-CSC
    TI__Guru 61575 points

    Hi,

    I don't know of any guidelines for external tool. Since it is CC31xx device, it only requires servicepack and system/configuration files that are flashed via Uniflash. I usually use the external standalone tool to prepare and program the image (and not the CCS or sysconfig). The 8/16/32 bits are set in the platform code (cc_pal.c/h). Or am I missing anything?

    Shlomi