I am trying to port the PMSM motor control example application to freeRTOS on the imxrt1050. After implementing the main routines in freeRTOS tasks, I cannot establish a connection to the FreeMASTER desktop client. Following the communication driver user guide and this question (https://community.nxp.com/t5/FreeMASTER/Freemaster-FreeRtos/m-p/1283261), I did these steps:
1. Switched to FMSTR_SHORT_INTR
2. Set FMSTR_COMM_RQUEUEM_SIZE to 32
3. Created a low-priority RTOS task that calls FMSTR_Poll() in its loop, the task runs only when other tasks are in blocked state (it has priority = tskIDLE_PRIORITY+1).
What am I missing?
Thanks in advance for any help
Dear @Haitham_Ismail,
your modifications look correct to me except a minor typo: the correct name of the macro is FMSTR_COMM_RQUEUE_SIZE. Can you add some counter variable or some other mechanism to make sure the FMSTR_Poll is indeed called in the low-priority task at least once a while? Also, check if you call the FMSTR_Init at the beginning of the task.
After trying to connect with FreeMASTER tool, you could also check the fmstr_rxQueue and fmstr_rxBuff variables (static in freemaster_serial.c) to see if there are any data bytes received.
Regards,
Michal
Thanks for the help @MichalH,
I tested using a counter to check if the FMSTR_Poll is called, and watched the fmstr_rxQueue/Buff variables. The counter was not incremented and the variables did not change when I tried to connect to FreeMASTER.
After some testing, it seems that the ADC interrupt is starving the RTOS tasks. To give more context:
The ADC interrupt is executed each 100us and is responsible for the execution of the state machine fast loop which should not be interrupted even by other interrupt routines.
A quad timer is used with a period of 1ms, when its interrupt is executed it defers to a task to execute the state machine slow loop routine.
- freeRTOS Clock rate: 528000000UL (system default)
- freerTOS Tick rate: tried 1k-10k-100k
What should I do in this case?
Hello,
So it means there is some other (higher priority) task still running without ever going to sleep - probably the slow-loop task.
You might try to examine the slow-loop task if it ever executes any wait-for-event code. If I understand it well, the quad timer ISR sets an event to wakeup the slow-loop task. The task should process the interrupt and go back to wait state, otherwise it will never give a runtime to anything else.
Alternatively, you could switch the freemaster driver to use FMSTR_LONG_INTR mode. In this mode, all communication is taking place in the UART interrupt, so you would not need to solve the task prioritization issue. But this is more a workaround. I think that what you describe indicates that there is some problem in your task scheme and you should investigate whether your tasks run as you planned.
Regards,
Michal