Hello!
I am developing an application which uses GPS attached to UART, everything is working fine but at startup sometimes my system stucks, I have increased the stack of every task to give it enough head room.
An interesting issue with my firmware is that, as soon as I initialized UART data starts coming from GPS and I use xStreamBufferSendFromISR to send data from ISR to task. So the problem is data keeps coming right after initialization but I haven’t started the scheduler yet.
Do you think this may be the reason of my system getting stuck, and I also want to ask that what will happen if xStreamBufferSendFromISR is called but the scheduler is not started yet.
Calling FreeRTOS functions from an ISR before the scheduler starts can cause problems, as would using the handle for the buffer before you create the buffer (since the handle value would be invalid)
This is the reason that all calls to FreeRTOS functions will disable the interrupts, which will then be enabled when you start the scheduler. If you are overriding this behavior then you are “shooting yourself in the foot”.
The answer would be to just not enable the interrupts manually before the scheduler starts.
Thanks for your message, during system initialization when I call xTimerCreate() I had to enable the interrupt again, because I am using core timer interrupt to generate the delay with a resolution of 1 ms.
I think the root cause of the problem is that I am enabling the interrupt, but it is almost impossible to disable the interrupt before starting scheduler since a lot of communication for initialization of ICs require interrupt, what would be the way around!
Which hardware are you using? Depending on that, you may be able to raise the priority of the interrupts you need to enable higher than configMAX_SYSCALL_INTERRUPT_PRIORITY and then you can enable it. Note that you will not be able to call any FreeRTOS API from the ISR.
If you are using Cortex-M, this page provides detailed explanation - RTOS for ARM Cortex-M
What interrupt do you need before starting the scheduler? Are you calling any FreeRTOS API from the ISR? If not, can you try setting its priority higher than configMAX_SYSCALL_INTERRUPT_PRIORITY?
The basic answer is the stuff that needs interrupts should be done AFTER the scheduler is started. That might mean some tasks aren’t created (or block waiting for an appropriate signal) until you get your hardware fully initialized.
The other option is that ALL your ISRs need to check a flag to see if the kernel has been started, and not use any of the FreeRTOS API’s until then, but that adds cost for all the time the system is running.
Note, there is no rule that you can’t start the FreeRTOS scheduler before your hardware is fully initialized, you just need to initialize it enough to allow the system to start running. This may even allow the system to be ready faster, as during the time one device is waiting for.a timeout, another can be doing its work, as opposed to needing to do each one in series.