I’m working on a silicon labs MCU (LG230 - this is a cortex M3 device), and i seem to have a problem with the LEUART, when FreeRTOS is running. it appears that characters sometimes aren’t received by the MCU. this only happens when the OS is running.
this is the test setup:
a host that constantly sends sequential characters (0, 1, 2…) to the device’s LEUART, buadrate 9600, no parity, 8 bits.
the device receives a character and checks if it matches what was expected (starting with 0, the device increments the next expected value - 0 received, the next expected is 1, and so on. overflow is taken into consideration). this happens in an infinite loop.
if the device receives the correct character, it replies with an “A” character. if the device receives a wrong character (3 when expecting 2, etc.) it replies with a “N” character. these characters are used to trigger a scope that can be triggered by serial data). This is implemented in an ISR, not in a task.
after a few minutes the scope always triggers - when checking the scope, i see that the device didn’t reply at all for a few characters (no "A"s or "N"s), causing it to fail once it is “restored”.
checking the scope, the signals are very clean - no noise was found to indicate a reason why the character might be lost.
I thought that the problem might be related to moving in and out of sleep (EM2), so i performed the following tests:
I ran the test, but prevented the OS from moving the MCU to sleep (it remained in EM0) - the problem persisted.
I ran the test, disabled the OS, and prevented the MCU from going to sleep (it remained in EM0) - the problem was gone.
i ran the test, disabled the OS, and created an infinite loop with a single “go to sleep (EM2)” line in it - the problem was gone.
the conclusion is that moving in and out of sleep, isn’t related to the problem.
in this test (when the OS is active) there’s a single task that is doing nothing but vTaskDelay.
the ISR doesn’t use any OS functions.
in the real system, this task uses OS “fromISR” functions, and i used NVIC_SetPriority to set the interrupt’s priority correctly, so the OS recoginzes it, though it is irrelevant for the test above.
If anyone is familiar with such a problem, or how to further investigate it, please help.