UART2 issues when recovering from VLPS on the K50 Processor

[thasin_akhand]

Hi,

I see framing issue when I send a serial message via UART2 on RS485 line with 9600 baud rate with data size of 8-bit, and no parity. This issue happens when I had implemented VLPS. When the VLPS wakes up from uart rising edge, I do set the processor back to PEE (with PLL locking), however I am still not receiving any messages. I read in some forums to use external clock for your uart, but what if you don't have an external clock and the reference manual says the UART2 is operated by the bus clock only? The bus clock is affected by entering the VLPS, so my question is, is there any other solution or am I missing something? Run to VLPS currently switches in freeRTOS idle hook. 

I am using #MK50DX256CMC10 kinetics processor. 

Thank you. 

Regards,
Thasin

[mjbcswitzerland]

Hi

Did you check out: https://community.nxp.com/message/421247#421247 ?

Regards

Mark

[thasin_akhand]

Hi I got it working (somewhat).

I saw whenever I sent a serial command, the processor would wake up and the UART_TransferHandleIRQ(..) would be invoked. I assume the previous guy, who implemented the UART, enabled active edge interrupt since the manual said only active edge can wake up the processor from STOP mode. So I thought it was already implemented, however it seems kUART_RxDataRegFullInterruptEnable was the interrupt the IRQ was handling.

So I enabled the UART's kUART_RxActiveEdgeInterruptEnable, have the UART_TransferHandleIRQ disable active edge interrupt (so that it doesn't trigger on every active edge), and disable VLPS mode using a flag. Once the request uart request finishes I re-enable the power mode flag and the active interrupt. The Uart IRQ only disables the active edge interrupt if it is able to clear the active edge flag, so only handles from active edge interrupt. After that it seems to work!

Since our product rarely uses the UART port, we were able to afford having the power mode disable during the period of time the uart finishes its messages. However we saw another problem during test, the STOP mode would stop working for a period of time while running our product! I assume this could be due the flag being set to turn off the power mode and it does not set it back, which then my background task never enters VLPS mode. However how can this be, since the uart irq should only be invoke when user sends a command? This happens during runtime where there should not be any Uart request. 

We are checking if its due to some sort of power surge to the uart rx that's triggering the uart IRQ. One test I did was to remove usb-to-rs485 from my computer which connects to the device, then putting it back to my computer and I saw uart irq was invoked.

So here are my following question.

1. Other than a power surge, what can possibly trigger uart IRQ?

2. Is there a way for using the uart without disabling VLPS or STOP mode? 

3. we are using UART 3 (not 2 as told in the original request, my mistake), so it uses the bus clock. Would it be better to use the partial Stop mode instead, where it disable the system clock but the bus clock is enabled? The partial STOP mode is running at a acceptable consumption, though I would say we are at border line at this point. 

4. Is there anything else I need to watch out for? 

I have read the your link that was posted in the past. I'll read it again so hopefully I find some of the answers to my questions. If some of these questions have already been answered in an earlier post, please point me exactly where I can look. 

Thank You!

F.Y.I the following uart interrupts are enabled for the uart.  

- kUART_RxDataRegFullInterruptEnable
- kUART_RxOverrunInterruptEnable
- kUART_FramingErrorInterruptEnable

- kUART_RxDataRegFullInterruptEnable

- kUART_RxActiveEdgeInterruptEnable

[jingpan]

Hi,

UART2 use BUS clock. When system back to RUN mode, UART2 should work. Please check if UART2 is closed or setting changed when implemented VLPS. Is the UART RX port is set correctly? Is the bus clock frequency changed?

Please also see the errata 5N22D which you can find at Arm Cortex-M4|Kinetis K50 100 MHz 32-bit MCUs|NXP .

Regards,

Jing