Hello,
I am using freeRTOS with msp430f5418 (medium data model).
my program have two tasks.
they are receiving data using two different queues.
The data is placed to the queue by ISR.
My problem is after some time the program is stopped responding.
I found that the ISR is putting data to queue but it is not received by the task.
By some more observation I found that the tasks are blocked.
But I didn’t issued any explicit block command.
I tried with disabling the vTaskSuspend method too.
But it is not working. Can anybody tell me why this happens??

The first thought that comes to mind, are your interrupts set up right. Interrupts using on FromISR and have a priority below maxMAX_SYSCALL_INTERRUPT_PRIORITY. Failure on either of these puts you at risk of corrupting FreeRTOS data, which could cause tasks to freeze.

Hello,
Thanks for your replay.
I didn’t defined maxMAX_SYSCALL_INTERRUPT_PRIORITY anywhere.
Also I searched for the maxMAX_SYSCALL_INTERRUPT_PRIORITY in my whole project (Including freeRTOS Source).
But I can’ t find any matches. Do I need to modefy the freeRTOS code for that??

small typo in name, it should be configMAX_SYSCALL_INTERRUPT_PRIORITY. It isn’t used in all ports, and maybe the MSP series don’t use it. It is used in ports that support nesting interrupts. That does still leave the possibility of an interrupt calling an API function that is FromISR.

Hello.
MSP supports nested interrupts. and I am enabling (and disabling) interrupts from within the ISR.
But still the freeRTOS doesn’t have the configMAX_SYSCALL_INTERRUPT_PRIORITY.
What shall I do?? I didn’t understand your last point (”That does still leave the possibility of an interrupt calling an API function that is FromISR. “). Can you please clarify it?? Do you mean I am calling a non FromISR function from an ISR? if yes, I am not doing that. Can the length of ISR can be a problem??

MSP supports nested interrupts.

Yes, nearly all microcontrollers do, but not all the FreeRTOS ports do, and the MSP430 FreeRTOS port does not.  That is why you will not find the constants that richard_damon is referring to.

and I am enabling (and disabling) interrupts from within the ISR.

That is most likely to be the source of your problem. Also, do you have stack overflow checking on? Regards.

Thank you for your reply sir.
I mentioned earlier that the program is working fine for some minutes.
If .enabling (and disabling) interrupts from within the ISR is the problem, why it works for some time??
I didn’t have stack overflow checking yet, I will do it soon…

Enabling and disabling interrupts in an ISR would only cause a problem when certain events happen in a fixed sequence, for example, when an interrupt nests at one particular point in the code.  Therefore, it is likely that you could run it for a long time and never see a problem because, co-incidentally, that particular sequence never happened.  The problem would only be intermittent. Regards.

Oh yes,
You are right.
It is happening for some fixed sequence. But my program needs nested interrupts as well as freeRTOS.
what shall I do??
Do you have any suggestions??

Can I do something like sending a special message to queue to disable/enable interrupts so that it is not disabled within the ISR. Is it a good idea?? what about the timing issues if I use this method? or can you tell me how to edit freeRTOS for msp430 to support nested interrupts?? Thanks in advance..

The basic problem is that the queue code needs to access some common data, and needs some form of exclusion method to protect this access. The FromISR routines use a routine provided by the portable layer to provide this, and that layer uses the assumptions of the port. For a port that doesn’t support nested interrupts, it assumes that no further interrupts are possible inside of the ISR, so no further protection is needed. You would need to update that layer to include the interrupt disable/enable code that you are using. Otherwise, at some point you will get an interrupt during one of these critical sections of code, and get a corruption of FreeRTOS data, which can cause tasks to get locked out.

Thanks for your reply
So you are saying that the FromISR functions must be modified.
Can I disable interrupts in the top of all FromISR function and restore it on the bottom of it?
is it a good way to do that?? you didn’t comment on my first suggestion.

Can I do something like sending a special message to queue to disable/enable interrupts so that it is not disabled within the ISR.

So you are saying that the FromISR functions must be modified.

No – the FromISR functions are all capable of working with ports that support nested interrupts already, but they rely on some port layer functions that are not implemented for some ports.  For example, they call portSET_INTERRUPT_MASK_FROM_ISR() (which disables interrupts up to a certain level, then returns the old interrupt priority mask) and portCLEAR_INTERRUPT_MASK_FROM_ISR() (which sets the interrupt mask to that returned by the first macro). All prots could be made to support nested interrupts.  How complex this is depends on the architecture.  The question is whether the architecture speed and RAM provision warrant doing it. I suspect the MSP430 could easily support a compromise where the tick interrupt uses the lowest interrupt priority, and any task that wants to use FreeRTOS “FromISR” API functions also use the lowest interrupt priority, then any interrupts that are above that interrupt priority just can’t use FreeRTOS API functions.  This is how the PIC24 port works.  Other ports have a much more comprehensive multi-priority scheme.

you didn’t comment on my first suggestion.
Can I do something like sending a special message to queue to disable/enable interrupts so that it is not disabled within the ISR.

I don’t understand the question, so can’t answer it either. Regards.

Thanks for your reply. My suggestion was this.
Since you said the interrupts should not enable/disable from the ISR, Can A task do that??
for that is it a good way to send a message to the queue which is associated with the task telling to disable/Enable the interrupts, so that the disable/enable is done within the task? I am a beginner to the freeRTOS and I am looking any other methods other than modifying the freeRTOS code. But if it is needed, I have to do it. I am expecting help from all…. Thank You

If you want to get your program to work without changing FreeRTOS, one big question that comes up is “Why do you need to use nested interrupts?” An interrupt when using an RTOS should generally be very short, not much longer than the time it takes to pull any appropriate date out of the hardware and into a communication structure, like a queue. Any processing that needs to be done, which might take time, should be done at “task” level (maybe a high priority task).

Ya I removed the nested Interrupt functionality from my program.
Now it is working fine…
Thank you very much for answering my questions…..
Regards
Hari