TI-RTOS task hangs when other task starts SimpleLink connection

Other Parts Discussed in Thread: CC3200

I'm working on a TI-RTOS application with the CC3200 Launchpad based on some example projects, and I have a problem where when one task connects to WiFi, another tasks stops running. I believe this is a stack or memory allocation issue.

I have a main task which is started based on the ti-rtos cfg file, and has a stack size of 15000. When that main task starts, it creates another task, which is responsible for periodically connecting to the Internet, performing some operations and disconnecting. After the main task starts the second task, it continues performing some other data collection operations (e.g. reading sensors).

If I let the main task connect to WiFi, the main task data collection continues fine, while the second task accesses the Internet. If however I have the second task make the connection (ultimately through sl_WlanConnect), the first task stops at the same moment the connection is made. This doesn't happen to other tasks, for example I have another task that monitors other inputs. This task continues running (along with the second task) when the main task stops. Also, the main task has priority 1, and the second and third tasks have priorities 2 and 3 respectively.

As I mentioned I suspect stack overflow or some similar issue. But I'm not too clear how to test for or resolve this. I was reading the TI-RTOS user's guide which mentions the ROV, and I tried to use this in CCS but I get this error: Plug-in com.ti.dvt.gridview was unable to load class com.ti.dvt.ui.views.core.PaneView.

I increased the stack sizes for all the tasks, and I also increased the SRAM_CODE and SRAM_DATA size in the .cmd file but this didn't seem to help. There are also some other settings (like Program.heap and Program.stack) defined in the ti-rtos .cfg file which I tried adjusting, but that also wasn't fruitful. I'm not too clear about these settings. I understand the stack is for hardware and software interrupts. So would I be safe to assume this stack size doesn't need to be very big? Right now it's 0x6000, but I see the SDK examples folder was app.cfg with this setting to 0x2000. The heap is set to 0x8000.

Where are the various task stacks located in RAM? After the bootloader, SRAM_CODE and the 'used' SRAM_DATA segments, there is some gap, and then the Program.stack size is located. Do all the stacks for the tasks I create like I mentioned above have to fit in the space in between, or is that all just heap? Or does the Program.stack size actually encompass all the task stacks? If I have no gap, will the extra available space above the Program.stack area be used for heap?

I'm listing the map file below. Currently I have my second and third tasks stack sizes at about 4000 and 2000 bytes (not 0x4000 and 0x2000). But I tried increasing the one the seems to cause the problem even up to 15kB and it didn't change anything. I tried trimming the SRAM_CODE and SRAM_DATA size to what was being used, and also tried increasing it since the .stack section is placed at the top of the SRAM_DATA segment and needs to fit in the 'unused portion of the SRAM_DATA segment (along with the task stacks and/or heap?). Note: I'm using the production version of the CC3200 launchpad.

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
---------------------- -------- --------- -------- -------- ---- --------
SRAM_CODE             20004000   00019000 000160c0 00002f40 RW X
SRAM_DATA             2001d000   00023000 000141ee 0000ee12 RW X

SEGMENT ALLOCATION MAP

run origin load origin   length   init length attrs members
---------- ----------- ---------- ----------- ----- -------
20004000    20004000    000160c8   000160c8    r-x
20004000    20004000    0000030c   0000030c    r-- .resetVecs
2000430c    2000430c    0001319e   0001319e    r-x .text
200174ac    200174ac    0000284e   0000284e    r-- .const
20019d00    20019d00    000003c8   000003c8    r-- .cinit
2001d000    2001d000    0000e1f4   00000000    rw-
2001d000    2001d000    0000dab2   00000000    rw- .bss
2002aab8    2002aab8    0000073c   00000000    rw- .data
2003a000    2003a000    00006000   00000000    rw-
2003a000    2003a000    00006000   00000000    rw- .stack

Can anyone shed some light on my questions and perhaps offer some suggestions on what might be happening or how I can tell? I was hoping to get some of the CCS debugger tools to help, or add some run-time logging/monitoring. For example I see a “Check for task stack overflow” option in the rtos config, but what happens if it detects it? Do I need to call some kernel function at run-time to retrieve this? Any idea how to get the ROV working?

Thanks,

Angelo

over 9 years ago

0 Emmanuel Trinidad - Alicea over 9 years ago

TI__Genius 10260 points

Hi Angelo,

Did you start your application from a TI-RTOS install or a CC3200 SDK example project?

AQ said:

If I let the main task connect to WiFi, the main task data collection continues fine, while the second task accesses the Internet. If however I have the second task make the connection (ultimately through sl_WlanConnect), the first task stops at the same moment the connection is made. This doesn't happen to other tasks, for example I have another task that monitors other inputs. This task continues running (along with the second task) when the main task stops. Also, the main task has priority 1, and the second and third tasks have priorities 2 and 3 respectively.

The TI-RTOS kernel is a priority preemptive scheduler, so tasks with a higher priority will execute before those with lower priorities. If your second task is constantly performing operations, the lower priority tasks will pend until all other higher priority tasks are blocked. Can you try making the priority for your main task and the second task the same? I think your application might be starving the main task.

AQ said:

There are also some other settings (like Program.heap and Program.stack) defined in the ti-rtos .cfg file which I tried adjusting, but that also wasn't fruitful. I'm not too clear about these settings. I understand the stack is for hardware and software interrupts. So would I be safe to assume this stack size doesn't need to be very big? Right now it's 0x6000, but I see the SDK examples folder was app.cfg with this setting to 0x2000. The heap is set to 0x8000.

Where are the various task stacks located in RAM? Do all the stacks for the tasks I create like I mentioned above have to fit in the space in between, or is that all just heap? Or does the Program.stack size actually encompass all the task stacks? If I have no gap, will the extra available space above the Program.stack area be used for heap?

The kernel has a system stack (Program.stack) and a system heap (BIOS.heapSize in cfg). The space for both of these is allocated at compile time (usually placed in .bss). The system stack is used when Hwi/Swi's are executing. This stack is shared by all Hwi/Swi's and while usually is not very large it depends on what is happening in the ISRs. The system heap is the space used when dynamically creating objects. When a task is created, it allocates a stack for itself taken from the system heap (each task has it's own stack and is not shared). It is good to have a large heap if you are dynamically creating multiple objects or tasks.

Since space for the heap is allocated at compile time, the gaps you are seeing is space which is completely unused.

AQ said:

As I mentioned I suspect stack overflow or some similar issue. But I'm not too clear how to test for or resolve this. I was reading the TI-RTOS user's guide which mentions the ROV, and I tried to use this in CCS but I get this error: Plug-in com.ti.dvt.gridview was unable to load class com.ti.dvt.ui.views.core.PaneView.

Can you post a screenshot of the error message?

AQ said:

I was hoping to get some of the CCS debugger tools to help, or add some run-time logging/monitoring. For example I see a “Check for task stack overflow” option in the rtos config, but what happens if it detects it? Do I need to call some kernel function at run-time to retrieve this? Any idea how to get the ROV working?

Hwi & Task stack checking can be enabled by adding:

/* Runtime stack checking is performed */
Task.checkStackFlag = true;
Hwi.checkStackFlag = true;

To your applications .cfg file. If a stack is overrun, the application will terminate with an error message indicating which task/Hwi failed. UIA and System Analyzer are tools for real time analysis of applications running on your target. Please see the System Analyzer wiki for more info (link).

Regards,

-- Emmanuel

0 AQ over 9 years ago in reply to Emmanuel Trinidad - Alicea

Expert 1570 points

Hi Emmanual, thanks for your reply and sorry for the delay.

Progress update:

After making some adjustments to stack sizes and other code changes the issue seemed to resolve itself, however I did a number of things so I can't be certain if there was a specific cause, or what it would be. The issue has since popped up again however, and after modifying reducing the CODE space to give up some more DATA space, that fixed it again.

Answers to your questions:

1. I'm quite certain the project was started from a CC3200 example project, although I'm not sure which. This was done by a previous developer working on this.

2. Can you confirm that priority 1 is the highest priority and higher value priorities (2, 3, etc.) are lower priorities? I have tried matching and inverting the priorities but it didn't seem to help at the time.

3. OK, it's good to get clarification on the heap space allocation. That means I have some extra RAM I can utilize.

4. I'm attaching a screenshot of the error.

5. Thank you for the advice on the stack checking, I will look into this further and see if it helps me identify optimal stack sizes for my tasks.

Thanks again,

Angelo

0 Nik-Lz over 8 years ago in reply to AQ

Intellectual 350 points

I believe higher numbers mean higher task priorities.
Regards,
Nick

Processors

Processors forum

TI-RTOS task hangs when other task starts SimpleLink connection