The delay function works fine, I have tested it by flashing the LED with the delay of 1 second. The problem arises when I call the xTimerCreate() function to create a software timer, when I call xTimerCreate the delay function stops working and stuck in while loop. It happens right after it, delay works before xTimerCreate() and stop working after it.
m_Milliseconds is a volatile variable to avoid optimization side effect.
I am not able to debug the issue since software timers has nothing to do with hardware timers . Help is greatly appreciated.
Is the scheduler started when you call xTimerCreate? If not, the reason may be that the timer ISR is masked and will be unmasked when you start the scheduler. If your timer ISR does not call any FreeRTOS API, you can set its priority higher than configMAX_SYSCALL_INTERRUPT_PRIORITY so that it is not impacted by FreeRTOS critical sections.
You should also look into using vTaskDelay instead of busy waiting to avoid wasting CPU cycles.
Thank you for your reply @aggarg. No the scheduler was not started when this happens. This happens in initialization of my system where I have not started the scheduler yet. Let me confirm if the timer ISR has stopped working…
@aggarg I have checked, the interrupt handler of core timer has stopped working. I have started the Core Timer again but it didn’t work. I have checked its priority as well, it is highest, problem is something else.
I have assigned the highest priority to core timer that is 1, the FreeRTOS port that I am using comes with MPLAB, I have just enabled it as third part libraries and my MPLAB provided me that FreeRTOS port along with other project files.
Hello! The update is, the delay function starts working after the scheduler is started, so some thing happens when the xTimerCreate functions is called which hinders the correct working of delay function, and that thing disappears after the scheduler is started. Now the question is what is that thing!!!
@RAc I have put portENABLE_INTERRUPTS(); after xTimerCreate and everything starts working. You were right interrupts was disbaled.
Now that it is working, my question is, is it safe or a good approach to put portENABLE_INTERRUPTS(); right after xTimerCreate is called. I mean manually enabling interrupt with portENABLE_INTERRUPTS() would be ok???
The reason the interrupts are disabled is that it is an error for an ISR to attempt a scheduler operation before it is started, so as a preventive measure, they are disabled in many FreeRTOS functions called before the scheduler is started.
Normally, an application shouldn’t be needing interrupts during this initialization time, things that need interrupts tend to be held off until after the scheduler is started.