FreeRtos Harmony V3 Linker Error

Some time the program run, sometimes the program crash in a exception.

I only reprogram the chip with the same firmware( i don’t change a comma in firmware ).

If program are running in the hardware board, and i turn off->wait some seconds->turn on power supply, the board does not return to work.

@rtel

Does the FreeRtos Kernel need more than one timer to work?

This software timer are strange here.
Core Software Interrupt 0. _CORE_SOFTWARE_0_VECTOR

The freertos tick timer use timer1.
Timer1. _TIMER_1_VECTOR

File: port.c

BaseType_t xPortStartScheduler( void )
{
extern void vPortStartFirstTask( void );
extern void *pxCurrentTCB;

	#if ( configCHECK_FOR_STACK_OVERFLOW > 2 )
	{
		/* Fill the ISR stack to make it easy to asses how much is being used. */
		memset( ( void * ) xISRStack, portISR_STACK_FILL_BYTE, sizeof( xISRStack ) );
	}
	#endif /* configCHECK_FOR_STACK_OVERFLOW > 2 */

	/* Clear the software interrupt flag. */
	IFS0CLR = _IFS0_CS0IF_MASK;

	/* Set software timer priority. */
	IPC0CLR = _IPC0_CS0IP_MASK;
	IPC0SET = ( configKERNEL_INTERRUPT_PRIORITY << _IPC0_CS0IP_POSITION );

	/* Enable software interrupt. */
	IEC0CLR = _IEC0_CS0IE_MASK;
	IEC0SET = 1 << _IEC0_CS0IE_POSITION;

	/* Setup the timer to generate the tick.  Interrupts will have been
	disabled by the time we get here. */
	vApplicationSetupTickTimerInterrupt();

	/* Kick off the highest priority task that has been created so far.
	Its stack location is loaded into uxSavedTaskStackPointer. */
	uxSavedTaskStackPointer = *( UBaseType_t * ) pxCurrentTCB;
	vPortStartFirstTask();

	/* Should never get here as the tasks will now be executing!  Call the task
	exit error function to prevent compiler warnings about a static function
	not being called in the case that the application writer overrides this
	functionality by defining configTASK_RETURN_ADDRESS. */
	prvTaskExitError();

	return pdFALSE;
}

That’s not the one. It’ the tempo variable in main() which may cause a problem.

I can not say if that is your primary problem or not, but it is a potential problem. It is not unusual for something like that to behave different on different ports and platforms.

edit:ok, if you ignore the task param and the problem still shows, your main issue is something different.

Is there anything else running in your system at all - any other interrupts or tasks or peripheral interfaces?

Have you tried increasing the stack depth (as per links provided previously)?

Do you have any calls to printf() in your code - from the images it appears to. Can you take those out to see if it makes a difference.

Are you using any kind of semihosting - if so - don’t ;o)

Does the board run “standalone” just by resetting, so without the debugger attached?

You didn’t answer me if freeRtos needs 2 timers to work. I think dont.

Thank’s.

No - FreeRTOS does not require two times. I think our demos all use peripheral timers as the core timer, if I recall correctly, is free running and has to be re-programmed “live” for the next tick - so there is a [small] chance it has already counted past the next required compare match value by the time you program the compare match - which would not be good.

Semi hosting is where IO from the target devices, such as console IO, is redirected to appear on your development machined - for example printf() output is shown in the IDE rather than output from the target (via a serial port, or whatever).

I’m not sure about your answer regarding running the board standalone without the debugger. I was meaning disconnect the debugger completely, power cycle the board so it has a cold boot without the debugger getting in the way, then see if the behavior is corrected or not. That might be what you have done, not sure though because you said you were monitoring the reset pin.

If this project is generated by MPLAB you may have to ask Microchip.

I already open a support to microchip more than a week ago.

Microchip is also checking, but only now, passed to the people who test with the hardware.

Hi,

Microchip support response:

The issue has been reported as bug and the team is planning to fix this issue.