Folks,

I am getting a weird problem where sometimes, when coming out of or going in to one mode (this mode is purely how I have written the software, nothing to do with FreeRTOS) in my keypad, the OS stops working properly. I can see that the keypad is reading keys and putting the keypress into a queue. However, the task that reads that keypress no longer gets executed. In fact, it looks like no other task, other than the one that reads keypresses and puts them into a queue gets pressed.

Can anyone give me any pointers as to what this might be happening? Google searches have talked about coming out of interrupt routines, but there are no interrupts being called in this mode.

Thanks!

I'm afraid nobody can even start to provide assistance as you have not told us which port you are using, or told us anything about the structure of your tasks or interrupts. For example, how are the key presses communicated?

http://www.freertos.org/FAQ-how-to-use-the-FreeRTOS-support-forum.html

Regards.

Fair enough.

I'm running the STM32 with Crossworks on bespoke hardware that's been running fine for well over two years. I haven't touched any interrupts from how it came.

Key presses are communicated via a queue:

xQueueSend(xKeyQueue, &MappedKey, portMAX_DELAY );

They are received here in a different thread:

if (xQueueReceive(xKeyQueue,&KeyInQueue,portMAX_DELAY) == pdPASS)

This and any other thread are no longer called. Only the thread that places key presses in the queue is now called.

This is the code it seems to get stuck going round and round in and not switching out of:

  for ( ; ; )
        {        
        xSemaphoreTake(xSPI1Mutex, portMAX_DELAY);
        NewKeys = GetAllKeys();
        xSemaphoreGive(xSPI1Mutex);
        if (NewKeys != 0xF0000000)
            {
            // Debounce done here 
            if (Change != 0)
                {
                Keys = NewKeys;
                FindKeyChanges(Change,NewKeys); 
                }
            Bounce = NewKeys;   
            
            vTaskDelay(50);
        }

Some details are included as comments for reducing amount of code. Is that any help?

Because your task calls vTaskDelay() another task should always execute. It might be that the only task that executes is the idle task if the task that receives the keys is in a state that does not allow it to continue. So the problem might be in the receiving task not the task that still executes.

As this is an STM32, did you call NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4); before starting the scheduler? This is apparently needed on ST parts but not normally other manufacturers Cortex parts because of differences in the initialized state.

Is you system using interrupts? If so, have you seen the pages on the FreeRTOS.org site about how to use interrupts on Cortex chips, and the most common sources of problem FAQ?

Dave, the tip about NVIC_PriorityGroupConfig seems to have done the trick, thanks. I commented it out, I think when I was trying to resolve a bootloader problem. This may stop the bootloader working, but seems to have sorted this. Many thanks.