CC3220: POSIX and TI-RTOS memory mgmt problems

Stuart Robertson

Part Number: CC3220

Hi,

I have migrated my CC3200 GEN1 project to CC3220 GEN2 however I cannot get my GEN2 s/w stable with POSIX.

With CC3200 GEN1 I only used TI-RTOS (modifying the UDPech example) and everything ran perfectly.

With CC3220 GEN2 while I wanted an exclusive TI-RTOS only solution (i.e. no POSIX) unfortunately I couldn't find one that also included a SimpleLinkNetAppEventHandler. I therefore ended up modifying the 'httpget' project (TI-RTOS derivative). This also uses POSIX. In the project I use the TI-RTOS static configurator for task, semaphore and clock function creation.

In short once the system has acquired a network address I'm getting errors (not all the time and different ones) when I start running my tasks. I have replaced the POSIX created httptask created in the platform.c file with a TI-RTOS call to my primary task in another file (as I see in some docs it says not to use Task_setPri() function from within a POSIX task, why not?).. The errors I get are typically on binding or creating sockets and often its error code -2005.

Without going into a huge amount of detail my question is a general one at this time: how to manage memory for task allocation etc between POSIX and TI-RTOS with the heap and stacks. Could I be having an overlap with POSIX and TI-RTOS memory mgmt. Clearly I'll have to revisit the RTOS/SYSTEM analyser tools etc but in the meantime I just wanted a general understanding of how the memory should be partitioned between POSIX and TI-RTOS.

Thanks for any inputs.

regards,

Stuart

over 6 years ago

0 Sarah P over 6 years ago

TI__Mastermind 38980 points

Hi Stuart,

I'll let the POSIX experts give you a more complete answer if needed, but I encourage you to check out the Gen1 to Gen 2 Migration Guide in the CC32xx SDK. It should answer a lot of your questions about the how to handle the change from the Gen 1 osi.h to the Gen 2 POSIX-dependent host driver: dev.ti.com/.../

Best regards,
Sarah

0 ToddMullanix over 6 years ago in reply to Sarah P

TI__Guru* 96960 points

Hi Stuart,

By default, TI-RTOS creates a "system" heap. The heap implementation supports variable size allocation. The actual heap module used is HeapMem. To use the heap, you can use Memory_alloc(NULL, size, align, &eb). TI-RTOS also supplies an implementation of malloc/free that resides on top of this system heap. So either allocation API acts on the system heap. Having said that, if you use Memory_alloc, you should free that block with Memory_free. If you use malloc, you should free that block with free. The reason is that malloc allocates a few extra bytes to store the size of the allocation, where Memory_alloc does not (you provide it in the Memory_free).

The information in Tools->ROV->HeapMem reflect both Memory_alloc and malloc allocations. And if you are using the debug kernel project or have enabled HeapTrack on the System heap, information in Tools->ROV->HeapTrack also reflect both Memory_alloc/malloc allocations.

I'm not sure what you are asking about the Task/pthread stacks. Each Tasks and pthreads requires it's own stack. With TI-RTOS, the stack can be provided via the Task_Params structure during creation. If not supplied, the creation will allocate a stack (based on the size in the params structure). By default the allocation occurs out of the system heap. For pthreads, the stack can be provided also via the pthread_attr_t structure. If none is provided, one will be allocated from the system heap (actually the allocation will occur in Task_create since pthread_create calls Task_create (and some other stuff).

Did this cover your question regarding memory management?

Todd

0 Stuart Robertson over 6 years ago in reply to ToddMullanix

Intellectual 840 points

Thanks Todd, it helped my understanding! Clearly I'll have to better embrace using the debug tools to find out what might be going wrong. Will likely come back with a related question when I'm more up to speed with everything.
rgds,
Stuart

0 ToddMullanix over 6 years ago in reply to Stuart Robertson

TI__Guru* 96960 points

Sounds good!

0 Stuart Robertson over 6 years ago in reply to Sarah P

Intellectual 840 points

Hi Sarah,

Thanks for coming back on this. I have studied the migration guide and do feel it went well i.e. made all the necessary changes, the project builds well but crashes. The major change is the inclusion of the POSIX layer. To be honest I invested a fair amount of time understanding TI-RTOS and in GEN1 it all went smoothly. I would so like to just to have the same TI-RTOS only solution in GEN2 but difficult for me to realise. Will get to know the debug tools better as outlined in Todd's email and take it from there.
rgds,
Stuart

0 Jan D over 6 years ago in reply to Stuart Robertson

Guru 79885 points

Hi Stuart,

I use application where main part was ported from CC3200. I don't not use static TI-RTOS configuration as you, but slightly changed osi layer from CC3200 SDK. During porting my code I remember a one issue. It comes in SDK version 2.20, where was changed structure of SimpleLink driver to support re-entrance. Maybe you can test SDK version 2.10 to be sure if you not have same issue. Because at version 2.10 and earlier was structure of SimpleLink driver for CC3220 more closer to driver for CC3200.

Jan