STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

Updated OS from 7.1.1 where everything was working fine, now i’m getting hardfault in xQueueGenericReceive. I’ve traced this down to uart rx interrupt, where the driver calls xQueueSendFromISR to put teh recieved data into queue. The uart interrupt is configured as:- NVICInitStructure.NVICIRQChannel = USART2IRQn; NVICInitStructure.NVICIRQChannelPreemptionPriority = configLIBRARYMAXSYSCALLINTERRUPTPRIORITY + 3; NVICInitStructure.NVICIRQChannelSubPriority = 0; NVICInitStructure.NVICIRQChannelCmd = ENABLE; NVICInit( &NVIC_InitStructure ); The freertos cfg is as follows:-

define configLIBRARYLOWESTINTERRUPT_PRIORITY 15

define configLIBRARYMAXSYSCALLINTERRUPTPRIORITY 5

/* The lowest priority. */

define configKERNELINTERRUPTPRIORITY ( configLIBRARYLOWESTINTERRUPTPRIORITY << (8 – configPRIOBITS) )

/* Priority 5, or 95 as only the top four bits are implemented. */

define configMAXSYSCALLINTERRUPTPRIORITY ( configLIBRARYMAXSYSCALLINTERRUPTPRIORITY << (8 – configPRIOBITS) )

The receiving task for the data in the queue is this, this task is running @ priority tskIDLE_PRIORITY + 3
while( 1 )
{
    if( xQueueRx != NULL )
    {
        /* block until something arrives in the queue */
        xStatus = xQueueReceive( xQueueRx, &cChar, portMAX_DELAY );

        if( xStatus == pdTRUE )
        {
            switch( pd->service )
            {
                case DAT_MODE:
                    data_mode_handler( pd, cChar );
                    break;

                case CMD_MODE:
                    command_mode_handler( pd, cChar );
                    break;
            }
        }
    }
    else
    {
        TSL_DEBUGF( ATH_DEBUG | DBG_TRACE | 1, ( "AtHandler:Queue Error! rn" ));
    }
}
The task stack is currently largely over what is needed, set to 512 at the moment with 476 free Why should updating to 7.5.2 break my system ? any suggestions welcome Why should upgrading break this ? what as changed in freertos that would do this ?

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

[This new forum is going to take a bit of getting used to! The formatting of your post came out a little strangely and I didn’t get an email notification of your post. Plus I don’t seem to be able to resize the window I am now typing into. Anyway, to your question…] There are some new assertions put into FreeRTOS V7.5.2 especially to catch misconfigurations. Although there is nothing obviously wrong with the configuration as you have shown it above it will be worth defining configASSERT() if you have not already. See http://www.freertos.org/a00110.html#configASSERT Also, have you called NVICPriorityGroupConfig( NVICPriorityGroup_4 ); anywhere in your code. That is only necessary if you are using the STM32 peripheral library as the library will silently fail if you don’t do this. Regards.

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

NVIC is NVICPriorityGroupConfig(NVICPriorityGroup_4); This is called prior to vTaskStartScheduler(); ConfigASSERT is

define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }

Richard one thing i think you are missing and this is my whole point, the application ran fine using 7.1.1, all i’ve done is swap out the freertos code to 7.5.2 and it is now broken. If i swap back to 7.1.1 all is good again. Something as changed significantly in 7.5.2 and that is causing the issues

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

Something as changed significantly in 7.5.2 and that is causing the issues
V7.1.1 to V7.5.2 is in fact a jump of 6 releases, so it is not necessarily something in V7.5.2 – but in any case all the changes should be backward compatible so a version change should not cause any issues unless stated in the history file. I think the last time that was the case was from moving from V4.x.x to V5.x.x (http://www.FreeRTOS.org/History.txt) I note your task stack has ample size. Could it be possible that the stack used by the interrupts is not large enough. Unfortunately there is no portable way of automatically detecting interrupt stack overflows. The stack used by the interrupts is the same stack used by main(), so will be defined in your project file or linker script. Which compiler are you using? Are you able to step through the xQueueSendFromISR() function to see where the fault occurs. You can also write a fault handler that will provide the address of the faulting instruction as well as the register values at that time. http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html Regards.

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

Hi Richard the current stack for interrupts is 0x400 this is the default value from the atollic project. Compiler is GCC. Note 7.1.1 does not have any issues, and is the save project, same linker file etc only difference is freertos code base. If it was the interrupt stack surely this would present teh same issue on 7.1.1 ?

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

It is possible as the code contains more configASSERT() statements so could potentially use more stack, but it is unlikely. 0x400 should be ok, provided the linker script is correct, and if you are using the Atollic tools you would hope the script was correct (assuming the script came from the tools in the first place). You could even try with configASSERT() undefined to see if that actually helps (ironically). Otherwise you will have to try and debug the abort using the code in the link above. That should tell us the code that actually aborts, and the parameters being used at the time. Regards.

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

Hi Richard, i believe the issue lies around this….. I create one task (called “vInitTask”), then call vTaskStartScheduler(); The job of vInitTask is to initialize the system, which in turn creates other tasks etc, i did it like this because i wanted OS functions available to help with the init process i.e there are certain tasks that rely on others to be ready etc…… Now when vInitTask is finished, in 7.1.1 i would call vTaskDelete at the end of the function (im using heap1.c and know this does not reclaim the used memory) but, in the 7.1.1 documentation examples vTaskDelete was used in this way. Right so moving on to 7.5.2, you added new asserts which failed on vTaskDelete as the memory model did not allow freeing of static memory etc…. so i tried vTaskSuspend hoping this would suspend the vInitTask, and then the tasks it created started running, but seem not. Calling vTaskSuspend just delays the hardfault. If a comment out vTaskSuspend the hardfault is straight away. int main(void) { xTaskCreate( vInitTask, ( signed char * ) “Init”, configMINIMALSTACKSIZE*2, NULL, mainINIT_TASK_PRIORITY, &h_InitTask );
vTaskStartScheduler();              
while( ETERNITY ){};                
} portTASK_FUNCTION( vInitTask, pvParameters ) { // does some init // create other system tasks etc // flashes some status leds
// now at the end what do i do ??

    vTaskSuspend( h_InitTask );
// vTaskDelete( h_InitTask ); }

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

Please try getting the address of the instruction that causes the hard fault, using the code already posted. Actually – forget that – if you are using a recent version of the Atollic then you will find a menu item that will do that for you. I can’t remember what it is called, but it tells you the PC and register values as they were when the fault happened. Regards.

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

08002cf0: ldr r3, [r7, #12] 08002cf2: str r3, [r7, #12] 104 psr = psr; 08002cf4: ldr r3, [r7, #8] 08002cf6: str r3, [r7, #8] 107 for( ;; ); 08002cf8: b.n 0x8002cf8 <prvGetRegistersFromStack+88> 111 { HardFault_Handler: 08002cfc: push {r7} 08002cfe: add r7, sp, #0 112 __asm volatile 08002d00: tst.w lr, #4 08002d04: ite eq PC is 08002cf8

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

Did this come from the Atollic IDE? If so, then you have to get the dump on entry to the fault handler – otherwise the dump will show you the function call point, rather than the fault handler entry point. Regards.

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

its not possible to stop before hardfault happens The issue is down to vInitTask and how do i end/terminate this task after it has finished its work ? at the moment the task runs a then falls of the end of the function, and then thus it hardfaults. portTASK_FUNCTION( vInitTask, pvParameters ) { } In 7.1.1 i used vTaskDelete and this worked ok no hardfaults portTASK_FUNCTION( vInitTask, pvParameters ) {
vTaskDelete();
} What does one do in 7.5.2 ?

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

its not possible to stop before hardfault happens
Can you not put a break point on entry to the hard fault handler, or insert a break point opcode as the first opcode in the hard fault handler, then use the Atollic tool to show you the offending program counter value? There is nothing wrong with either option to stop the init task. Deleting the task will leak memory, as you point out, if you are using heap_1.c, but that is not going to cause a fault. Suspending the task is less likely to cause a fault. You could zip up your project, including everything I need to build it, and send it to me using the address on http://www.FreeRTOS.org/contact and I will look at it, but I might not be able to run it. I’m afraid that unless it builds exactly as you send it I won’t be ablt to do anything with it, so make sure the project you send does not use any absolute paths, etc. Regards.

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

Hi Richard, i’ve just created a minimal program and this does not show the issue, but then again theres not much going on. Going to try and debug abit further and see if i can find out more detail.

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

Hi Richard, i finally got to the bottom of the issue, and freertos 7.5.2 was not the cause, was some slack programming on my behalf, but one thing does stand right, the hard fault never happened in 7.1.1, moving to 7.5.2 highlighted the issue. Strange but all is good now…….:-)

STM32F103 Freertos 7.5.2 – xQueueGenericReceive Hardfault

Hi Lee, what was the actual fix? I’m having the exact same issue, and I probably made the exact same mistake.