Stack overflow when using SimpliciTI

Reply

grifcj replied on 22 May 2009 2:27 AM

rated by 0 users

Stack overflow occurs when your stack (the dynamic memory structure that holds function variables, return addresses, etc.) grows in size and spills over into RAM that is holding program variables. This commonly happens when you have long chains of function calls and/or variables using too much RAM. Probably a crappy definition, but eh, I'm sure you can find a better one with not too much searching.

I assume you mean the linker is giving you some sort of stack overflow error? I'm not aware of any sort of run-time stack-overflow error message...don't think that's possible.

I had problems with stack overflow on my AP (v1.0.5 SimpliciTI). The MSP430F2274 only has 1 kB of RAM. Depending on the number of end devices you have and the size of your input/output queues, you can use this 1 kB up very quickly. I think the stack defaults somewhere between 64 and 128 kB with Code Composers. You can set it in the linker options under project preferences. If the RAM required for you I/O queues invades upon the stack's space, I think the linker will complain.

My stack overflow led to cryptic behavior and dropped SimpliciTI packets.

I decreased the size of my input/output queues and limited the number of end devices that could connect to the AP at any one time to 3. You can see my memory mappings here: http://e2e.ti.com/forums/p/3919/14650.aspx#14650

Reply

SSK replied on 22 May 2009 5:44 AM

rated by 0 users

Hello,

Thanks for your reply.

I just have one question to ask.

How did you restrict the number of EDs that can join an AP at any one time to be 3? What was the maximum number of EDs that you had in your application?

Also I am sure what you mean by "queue size"? Does the number of EDs affect the stack size? If so, how and why?

Thanks

Sharwari

Reply

grifcj replied on 23 May 2009 6:12 PM

rated by 0 users

Normal 0

I don't know what that Normal 0 means...I imported this from a .doc file and it screwed with all my formatting and added that.

I don't think the number of end devices affects memory usage in a very significant way directly. Sorry that my words seemed to convey that. The access point will store connection information for every end device, but I think the number of bytes required for this is insignificant when compared to the queues. Certainly seems so by investigating my memory mappings. However, the number of end devices you have connected to the AP and whether these are polling end devices or not should influence the size of your queues. Specifically, the output queue stores messages meant for polling end devices. Say you have 5 polling end devices. You’d want an output queue at least 5 messages long, so you could send out a message to each device at the same time, probably longer. This was how I was drawing the connection between number of end devices and memory usage. If you have fewer polling end devices, you can decrease the size of your output queue and save memory.

For setting the number of end devices, I assume you've seen some of the TI-provided sample code. They provide two configuration header files for setting device and network parameters. I think the names are smpl_config.h and smpl_nwk_config.h, but I'm not exactly sure. You edit the number of end devices by defining the parameter NUM_END_DEVICES (again, exact name may be a little different, I'm working off memory). If you’re using the AP as a data hub, it will only let the number of end devices defined by NUM_END_DEVICES join the network. If you’re not using the access point as a data hub, perhaps this information isn’t relevant.

In these configuration files, you also set the input and output queue sizes as well as the maximum application payload. The queue sizes define the number of SimpliciTI messages that the queue can hold. If you don’t like the name queue, think of it as a message buffer instead. The MAX_APP_PAYLOAD parameter defines the size of these messages, but doesn't account for the couple bytes of overhead. To reduce memory used by the queues, reduce the maximum app payload and/or the queue sizes. Roughly, the number of bytes required by a queue is PAYLOAD * QUEUE_SIZE.

Also, there are some protocol docs that you may want to check out, if you haven’t already. I think installing the protocol via the executable in swrc099c.zip will copy all the docs onto your computer for you. There’s a detailed SimpliciTI protocol doc, an API guide doc, etc. If you plan on using SimpliciTI for much longer, I suggest you read them in full. They’re rather short as technical docs go.