LEUART problems in Silicon labs LG230

Kernel
1

eldad-k wrote on Sunday, November 29, 2015:

Hi.
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.
Thanks.

2

rtel wrote on Thursday, December 03, 2015:

Sorry this post took a while to appear. For some reason it ended up in
a moderation queue, which happens from time to time, even though
moderation is turned off.

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.

Can you please post some code, I’m confused as to where the infinite
loop is if this is done in an ISR. Also, if a task is used, it would be
good to see how the data is passed between ISR and task.

3

rtel wrote on Thursday, December 03, 2015:

4

eldad-k wrote on Wednesday, December 09, 2015:

Hi.
My bad, the use of “infinite loop” in this context was wrong. I meant to say that sending the sequential characters by the host happens continuously, with no expiry or stop conditions.

sequence start:
Host sends a character through UART.

the device’s UART receives the character and triggers an interrupt.
the device’s UART ISR is called, and checks if the character is the expected one.
if yes, the device sends an “A” character as a reply. if no, the device sends a “N” character as reply. the UART is full duplex.

with OS active, there’s a single task in the system. its infinte loop only contains a task delay.
without an OS, there’s a main loop that calls the sleep function (SLEEP_Sleep();).