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.

CC3220S: 'Unwanted' Semaphores appearing: Memory problems

Part Number: CC3220S
Other Parts Discussed in Thread: SYSCONFIG

Hi,

H/w: CC3220S Launchpad for dev though a custom board also exists.

I am migrating a project which ran successfully using SDK2.3 over to the latest SDK (4.4) and tools (CCS10.2, SysConfig) so it can be upgraded with new features.

It is based on the httpget example and uses TI-RTOS. I make use of the TI-RTOS static configurator to create 3xTASKS, 4xCLK instances and 1xSemaphore.

All seems to have gone quite well and it compiles, links and runs (a little) before crashing. I've used ROV to capture 'Before Running' and 'After Running' diagnostic info. From this it looks like I'm already in trouble before even running with the Semaphore status (see 'Before Running' screen capture below) . It should use only one semaphore called 'BufferReady' but it appears to show many (with some uninitialised). I've cleaned the project but same result. There is an 'After Running' capture too which shows an exception however where this exception occurs isn't consistent. I believe this is likely a memory issue but I'm not sure how to proceed to find the cause. I have 'HeapTrack' enabled and I don't see any other kind of errors (like Stackoverflow),

One thing that I'm not clear on is the mix of POSIX and TI-RTOS, in particular how I've enabled my own tasks. I've modified the platform.c file in httpget such that instead of creating the httpthread=>httptask  when a successful IP is acquired, I have simply changed the priority of my lead task from -1 to 2 using Task_setPri(Task_HalfDuplexStateMchHandle, 2);  Snippet below along with screen captures. Any inputs most welcome! I'm tempted to try and use a native TI-RTOS solution not just to save memory and decrease some latency but I'm just more comfortable in that 'TI-RTOS' only environment.

In project httpget in platform.c I've removed code in red and replaced with code in blue:

void SimpleLinkNetAppEventHandler(SlNetAppEvent_t *pNetAppEvent)
{
int32_t status = 0;
// pthread_attr_t pAttrs;
// struct sched_param priParam;

if(pNetAppEvent == NULL)
{
return;
}
Display_printf(display, 0, 0, "Valid SL event\n\r");

switch(pNetAppEvent->Id)
{
case SL_NETAPP_EVENT_IPV4_ACQUIRED:
case SL_NETAPP_EVENT_IPV6_ACQUIRED:
/* Initialize SlNetSock layer with CC3x20 interface */
status = ti_net_SlNet_initConfig();
if(0 != status)
{
Display_printf(display, 0, 0, "Failed to initialize SlNetSock\n\r");
}

if(mode != ROLE_AP)
{
Display_printf(display, 0, 0,"[NETAPP EVENT] IP Acquired: IP=%d.%d.%d.%d , "
"Gateway=%d.%d.%d.%d\n\r",
SL_IPV4_BYTE(pNetAppEvent->Data.IpAcquiredV4.Ip,3),
SL_IPV4_BYTE(pNetAppEvent->Data.IpAcquiredV4.Ip,2),
SL_IPV4_BYTE(pNetAppEvent->Data.IpAcquiredV4.Ip,1),
SL_IPV4_BYTE(pNetAppEvent->Data.IpAcquiredV4.Ip,0),
SL_IPV4_BYTE(pNetAppEvent->Data.IpAcquiredV4.Gateway,3),
SL_IPV4_BYTE(pNetAppEvent->Data.IpAcquiredV4.Gateway,2),
SL_IPV4_BYTE(pNetAppEvent->Data.IpAcquiredV4.Gateway,1),
SL_IPV4_BYTE(pNetAppEvent->Data.IpAcquiredV4.Gateway,0));

sl_WlanPolicySet(SL_WLAN_POLICY_PM, SL_WLAN_ALWAYS_ON_POLICY, NULL, 0); // For minimal latency
Task_setPri(Task_HalfDuplexStateMchHandle, 2); // Enable Half Duplex State Machine task

/*
pthread_attr_init(&pAttrs);
priParam.sched_priority = 1;
status = pthread_attr_setschedparam(&pAttrs, &priParam);
status |= pthread_attr_setstacksize(&pAttrs, TASK_STACK_SIZE);

status = pthread_create(&httpThread, &pAttrs, httpTask, NULL);
if(status)
{
printError("Task create failed", status);
}
*/
}
break;
default:
break;
}
}

Before Running

After Running


rgds,

Stuart

  • Hi Stuart,

    what is the status when you are not replacing the code?

    The extra semaphores may be allocated by the host driver / HTTPCli library. Did you check ROV with your app on SDK2.3?  

    Merging TIRTOS with POSIX code can lead to issues.

    You should pick one interface and stick to it (but note that the entire SDK is based on POSIX, i.e. the driver and the libraries are using POSIX).

    Br,

    Kobi

  • Hi Kobi,

    Thanks for the prompt response.

    what is the status when you are not replacing the code?

    The extra semaphores may be allocated by the host driver / HTTPCli library

    I think you may be right. When I run the httget appl from the 4.4 SDK and use the ROV I get similar results for the semaphore status (see screen capture below).

     

    Did you check ROV with your app on SDK2.3?

    No I didn't at the time however it did appear stable over many boards (similar methodology).

     

    Merging TIRTOS with POSIX code can lead to issues.

    You should pick one interface and stick to it (but note that the entire SDK is based on POSIX, i.e. the driver and the libraries are using POSIX).

    I had thought it was all stable now. Well the exception in the SDK is the PortableNative demo example which is native TI-RTOS though there is no networking/wireless going on in that appl. In your opinion is a big effort to add this in ? (Regarding POSIX what's done is done and if it eases the support burden for TI and increases silicon sales then I guess it must be the correct decision. However from my viewpoint I see a further abstraction layer using up more memory and slowing performance, losing the use of great tools like the static configurator, just a far less elegant solution. Ok that's my 10cents!) 

     

    Could you at least give me some pointers as to what to look out for in terms memory mgmt to see if there is a quick fix as the alternative looks like some significant effort (i.e time consuming).

    thks & rgds,

    Stuart


     

  • what is the status when you are not replacing the code (i.e. if you use the pthread_create instead of changing the thread priority)?

    I'm not familiar with specific issue in regards to memory management. There were issues in regards to sync objects between pthread based service to TIRTOS ones.