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