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:-

/* The lowest priority. */

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

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! \r\n" ));
	}
}

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 ?

[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.

NVIC is NVICPriorityGroupConfig(NVICPriorityGroup_4);

This is called prior to vTaskStartScheduler();

ConfigASSERT is

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

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.

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 ?

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.

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, mainINITTASKPRIORITY, &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 ); }

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.

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 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

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.

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 ?

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.

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.

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.......:-)

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