iMX6UL Wakeup from UART without losing data

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iMX6UL Wakeup from UART without losing data

1,403 Views
gga
Contributor I


Hello,

I am using an iMX6UL evk in combination with a µC module. The  µC is connected to the iMX's UART2 (ttymxc1, since I'm using the default dt configuration provided for the 14x14 evk). The evk is running a Yocto Linux image with kernel 4.1.15.

My application requires the iMX6 to be in the lower possible power state for most of the time, so I've configured it to enter DSM mode (using "echo mem > /sys/power/state") and wake up on interrupts from the UART pins, so that whenever the µC module has any data to transmit, the iMX can wake up and handle the coming messages. Wake up on UART is configured echoing "enabled" into the corresponding sysfs "wakeup" entry.

What I'm currently achieving is:

  • the communication between the iMX and the µC works correctly when the iMX is NOT in DSM mode;
  • the iMX wakes up correctly in about 120 ms when some data is transmitted from the µC module, but I'm not seeing any UART message being reported to my application. To be noted that the message sent from the µC module to the iMX is of few (1 to 10) bytes @ 115200 bps. The µC module never changes its state, so it is expected to have a consistent behavior independently from the iMX power state.

My questions are then the following:

  • Should I expect to receive the message when the system is woken up from UART (so by the message itself being transmitted) or is it normal that at least some byte is being discarded?
  • If I should expect to lose some data with my current configuration, what changes should I perform in order to avoid losing any message? In other words what would be the most (power) efficient way to wake up the iMX6UL from UART without losing any message?

Thank you for your help

Giorgio

Labels (4)
4 Replies

799 Views
igorpadykov
NXP Employee
NXP Employee

Hi Giorgio

first character could be lost as mentioned in sect.53.8.2 UART Operation

in System Stop Mode i.MX6UL Reference Manual

http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6ULRM.pdf

When an asynchronous WAKE (awake) interrupt exits the ARM platform from STOP

mode, make sure that a dummy character is sent first because the first character may not

be received correctly.

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

799 Views
gga
Contributor I

Hi Igor,

thank you very much for your reply.

The manual says that I should lose a character, but experimentally I'm noticing a different behavior using the 4.1.15 kernel and the provided yocto image.

I'm testing such behavior setting up the serial port (@155200 bps) and issuing a "cat /dev/ttymxc1" command, since the external µC module is sending out ascii chars (i'm testing it sending periodically the "1234567890abcdefghijklmnopqrstuvwxyz" string).

If the iMX EVK is in RUN mode everything works as expected, the message is correctly shown in the console.

If i put the iMX in STOP mode (issuing the "echo mem > /sys/power/state" command) it wakes up correctly as soon as the µC transmits the message, but the string printed out by the cat command is something like "tuvwxyz", so i'm losing much more than a single char.

It looks like some data is lost before the system is woken up. Could it be a driver or configuration related issue?

How can I further investigate the issue? Do you have any debugging hint?

Best Regards,

Giorgio

799 Views
evgenyerlihman
Contributor IV

Hi Giorgio,

Have you had any progress with this issue?

Thanks,

Evgeny

0 Kudos

799 Views
BiyongSUN
NXP Employee
NXP Employee

You need to have flow control.

Because during the waking up, the clock is very slow at that time.

It is not fast enough to read the data out from fifo.

0 Kudos