I have a setup where I use two raspberry Pi boards and establish communication over UART. Both boards have a freertos ported running on them. Both boards have one task and data is exchanged within this task. Meaning when one board sends, other reads and viceversa. The uart impl is blocking, so it waits until required amount of data is received. I want to test the limits of task scheduler and task timings while using uart. I’ve noticed a strange issue.
Issue: When I increase the task priority of first board, communication is disrupted and data exchange is somewhat halted. And strangely, when I pull/plug the uart cable between boards, the communication resumes(?). I can freely change the task priority of second board so it seems to be a problem with the first board. What could be the problem here? Does the RX somehow drops into interrupt and stays there? At this point I am stuck and exhausted anything that comes to my mind. Any idea/recommendation is appreciated.
Impossible to make any guess without more info. Does your UART driver support hardware handshaking? That would be about the only explanation for the resume after replug phenomenon.
Apologies for not being able to provide more information. My boards are Raspberry Pi4 and Pi0, both of them does not officially support FreeRTOS. I’m working on some github ports, to this point both seemed working almost perfect. For Pi0, the task priority is OK, i can manipulate all. Problem occurs on Pi4. Pi4 is also a custom port, it has 4 cores. I utilize u-boot and startup macros to hijack 3rd core, freertos runs on this last core.
And this is the reason that I do not have a debug environment. I believe I can remote debug the pi0 but pi4 is kind of harder, I am not even sure I can do it without doing some shm shenanigans.
For handshake, I doubt it, because the driver is generic, afaik, Pi4 uses standard PL011 driver and Pi0 uses bcm2835_aux.
What confuses me is, everything works with idle priority. Can task scheduler be the culprit here?
Culprit is the wrong term. There may be indirect effects such as different timing that affects a poorly designed architecture (for example if something assumes hard coded timeout periods that assume exclusive access). The scheduler will of course affect timing, that is sort of what it is there for.