I am facing a problem with a reception process: I have an stm32f429
discovery connected to a gsm/gps module held on an evaluation board. The
communication between the discovery and the module take place via UART. I am
using STM32Cube_FW_F4_V1.5.0 along with FreeRTOS V8.1.2 and everything is
developped on Eclipse Mars.
In my application I need to access to the Internet via gsm, then login to a
remote server and send some info to it. Therefore, I arranged everithing as
there are two tasks, say A (the low level task) and B (the application
task). Basicly, task A must ensure to task B that the module is powered on,
the SIM PIN is inserted, the AP is configured and the module is connected to
the Internet. On the other hand, task B waits for task A to notify that the
module is ready in the meaning I just explained.
Both task A and B implements two corresponding finite state machines. So, at
the beginning task A goes to the UNKNOWN state while task B goes to the IDLE
Then, task A send some AT commands to the module and waits for the responses
in order understand which is the module state. Then based on this knowledge,
it performs some actions to bring the module fully operative for task B. The
transmission/reception is obtained by means of the HALs functions
HAL_UART_Transmit_IT/HAL_UART_Receive, and the first is non-blocking while
the second is blocking with a timeout. The transmission is non-blocking
since the module replies very rapidly.
In the beginning the reception was puzzling. In the reception buffer I was
always finding odd chars, like due to something that was interrupting the
reception many times. Debugging (with the STATEViewer plugin) I came up with
the idea that that could be related to the fact that task A and B had the
same priority and then I tried to assign a higher priority (wrt task B) to
task A and everything worked fine. Based on this, I put some
osThreadSetPriority(), which is provided by ST within STM32Cube/cmsis_os.c,
in task A and B: when task A ends its job and notify to task B that it can
leave the IDLE state, then task B start performing some
HAL_UART_Transmit_IT/HAL_UART_Receive calls and therefore it needs to have
its priority higher than that of task A.
My question is: is this solution correct? Is really the reception process
integrity related with the task priority? There are many other tasks in my
application, and I started developping by assigning equal priority to
everyone leaving the “tuning” in the end because of the lack of time. But
now it seems that this approach could bring to a bad behavior. What if two
tasks must perform transmission/reception via different peripherals?
Thank you for the advice and regards.