I have an application runnign with about 8 taks in it now.  most of them are very small tasks that do simple IO monitoring and hence have nice small stacks.  The problem occurs that my debug serial port works absolutely fine until the main control thread hits a certain point at which the serial thread stops running ( the queue from the ISR is still having bytes pushed in, but the main worker thread seems to not to pull them out any more).  The code in the main control code is nothing special, just doing some IO related functions.  when it gets back out of that code, the serial task starts up again straight away.  I realise that this a rather vague posting, but i am getting really frustrated as to why its not working.  i’m really after things to check etc – stack sizes? heap size? things getting over written?  the code is running on an ARM AT91Sam7S64.  if i change the way the controller code runs so it is very simple ( but no longer properly functional ), the problem does not occur. thanks in advance for any thoughts or suggestions of ideas to help. regards Andy

To try and understand what you are saying. Out of your eight tasks there are two that communicate on a particular queue.  These tasks work fine unless the control task is operating. When the control task operates the two tasks using the queue seem to stop (at least the task taking data from the queue, seems to stop), but starts again when the control task blocks. Presumably the control task is lower priority than the task that stops, otherwise the behavior you describe would be expected. I don’t think it will be a heap problem as the heap is only used when tasks or queues are actually created. Stack problem is probably not the issue either as this normally causes a crash – but check this first. Is your control task using a critical section that is too long?  Or is it locking the scheduler for too long?

not quite, the debug serial thread simply has a queue to the ISR routine that pushes newly received bytes to the thread via the thread.  The control thread reads ADC channels and looks at IO pins for a lot of what it does.  is it possible that TCB sections overlap in memory or something such that the TCB / thread data for the debug port gets somehow stomped over?  i’ve tried jugglign stack sizes and have used the tasklist function to prove that the tasks have more than enough free stack space.  once all the tasks have started, there is no dynamic variable allocation within my processes so feel confident that the inital stack free values would be constant over the life of the thread running ( for ever ).  Andy