|
|||||||||||||||
FreeRTOS Support ArchiveThe FreeRTOS support forum is used to obtain active support directly from Real Time Engineers Ltd. In return for using our top quality software and services for free, we request you play fair and do your bit to help others too! Sign up to receive notifications of new support topics then help where you can.
Loading
FreeRTOS 8.2.1 mutexPosted by rzingler on November 19, 2016 Hi, I'm having problems with a mutex, used to protect the access to an external Flash memory. Randomly, a task that uses the mutex (I don't know if only one or more than one), for an unknown reason, accesses the external Flash memory without first taking the mutex, and, consequently, corrupts the memory data. I discover that by turning on a LED immediately after taking the mutex, and turning the LED off again before giving the mutex. When any task, after taking the mutex, detect the LED already ON, I show an error message, indicating the error (I made it on all tasks that access the mutex/external Flash). I have already activated stack overflow detection, an all the tasks are OK, even after the problem occurs. The problem sometimes appears in less than 1 hour, sometimes after almost a day. The project characteristics are as follows:
Here is the task used to take the mutex and store the data on external Flash. ~~~ static void taskStoreReadings( void *pvParameters ){ unsigned char *ptr; unsigned short indice, sectorNumber, vectorIndex; unsigned int memAddr; struct elecSensorData elecSensor; struct rainWindLightData mecSensor; struct sensorLogData sensorLog; } ~~~ Any help would be appreciated. Thanks. FreeRTOS 8.2.1 mutexPosted by rtel on November 20, 2016 Thanks for providing the detailed information - I wish more posters would do that! The cost you posted does not show where the LED is set and cleared. Am I correct in assuming you set it immediately after the following line: while( xSemaphoreTake(spiSemaphore, portMAX_DELAY) == pdFALSE ); and clear it again immediately before the line: xSemaphoreGive( spiSemaphore ); Which other tasks use the mutex? Is it more instances of taskStoreReadings(), or different implementations. If the latter could you show the other tasks too (cut down if necessary). Is the mutex used from an interrupt at all? FreeRTOS 8.2.1 mutexPosted by rzingler on November 20, 2016 Thanks for the quick response. I've already removed the lines that sets/clears the microcontroller's LED pin (it was just a test to indicate me something goes wrong). But, yes, they were placed as you presume (setting immediatley after taking the mutex and clearing immediately before giving the mutex back). There are not more instances of taskStoreReadings(). The mutex is not used from any interrupt. Below are the other tasks that uses the mutex. ~~~ static void taskBlinkLed( void *pvParameters ){ unsigned short seconds= 0; unsigned int opTime; } ~~~ ~~~
static void taskSendLog( void *pvParameters ){
unsigned char
mac[6],
index,
*ptr,
count; } ~~~ The last two tasks are defined in a different file, so the mutex created in main.c is passed as a parameter, as below (in the third line inside the function, the local variable spiSemaphore points to the same place as the mutex created in main.c): ~~~ void httpRequestInit( QueueHandlet *serverResponseQueue, QueueHandlet *lcdQueue, SemaphoreHandle_t *spiSem ){ } ~~~ FreeRTOS 8.2.1 mutexPosted by davedoors on November 20, 2016 A lot of data is being written into httpData. Could it overflow? Which TCP/IP stack are you using? Does it try and free memory (noting you use heap_1 which cant free memory). Maybe the mutex is getting corrupted. Try adding a new global variable: TaskHandle_t Holder = NULL; After every call to take the mutex (xSemaphoreTake) add the following: // No other task should have the mutex configASSERT(Holder==NULL); // Set Holder to show a task has the mutex Holder = xTaskGetCurrentTaskHandle(); // Check the mutex agrees who the holder is configASSERT(Holder==xSemaphoreGetMutexHolder(spiSemaphore)); // The mutex should be empty configASSERT(uxSemaphoreGetCount(spiSemaphore)==0); // Should not be able to take the mutex again (unless its a recursive mutex) configASSERT(xSemaphoreTake(spiSemaphore, 0)==pdFAIL); Clear Holder again immediately before giving the mutex back: Holder = NULL; Do any of the configASSERT() calls fail? If so, look at the spiSemaphore structure in the debugger. Does it look sane? You might have to cast spiSemaphore to: ((xQUEUE*)spiSemaphore) to view it. FreeRTOS 8.2.1 mutexPosted by rzingler on November 26, 2016 Hi, Dave. I included the configASSERT macro calls as you suggested, and they haven't failed when the problem appears. Could it be perhaps a stack overflow in any of the ARM7 modes? The task stacks are not overflowing (I've the overflow detection enabled). Thanks. FreeRTOS 8.2.1 mutexPosted by davedoors on November 26, 2016 If the asserts dont fail then its probably not the mutex and something else is happening. It could be one of the other stacks, IRQ or SVC, its easy enough to increase those to see if the behavior changes. FreeRTOS 8.2.1 mutexPosted by rzingler on December 12, 2016 Hi, Dave. It´s working now. The problem was generated by some macros used to set/clear variables and registers bits. These macros did read-modify-write operations, and sometimes, due to the multi-task environment, a call was made after the current call has ending its work, and so corrupted some GPIO´s (perhaps the pin used to control the CS signal of the external memory). This behavior deceived me also in the case of the debug LED I mentioned. Thanks for the help.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|
|||||||||||||||
NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.
Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019
Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.
View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.
FreeRTOS and other embedded software careers at AWS.
