atClientDaemon RxParser losing bytes

[langestefan]

Hi, I have recently encountered an issue when using the unsollicited response parser from the Legato AT client.

When reading the debug logs I see the following:

Jun  9 15:35:00 swi-mdm9x28-wp user.debug Legato:  DBUG | atClientDaemon[888]/atClient T=atCommandClient-7 | le_atClient.c CheckUnsolicited() 397 | Start checking unsolicited
Jun  9 15:35:00 swi-mdm9x28-wp user.debug Legato:  DBUG | atClientDaemon[888]/atClient T=atCommandClient-7 | le_atClient.c CheckUnsolicited() 411 | unsol found
Jun  9 15:35:00 swi-mdm9x28-wp user.debug Legato:  DBUG | atClientDaemon[888]/atClient T=atCommandClient-7 | le_atClient.c CheckUnsolicited() 447 | Stop checking unsolicited
Jun  9 15:35:00 swi-mdm9x28-wp user.debug Legato:  DBUG | atClientDaemon[888]/atClient T=atCommandClient-7 | le_atClient.c ResetRxBuffer() 565 | 36 sizeToCopy 2 from 34
Jun  9 15:35:00 swi-mdm9x28-wp user.debug Legato:  DBUG | atClientDaemon[888]/atClient T=atCommandClient-7 | le_atClient.c ResetRxBuffer() 577 | new idx 2, startLine 2
Jun  9 15:35:00 swi-mdm9x28-wp user.debug Legato:  DBUG | atClientDaemon[888]/atClient T=atCommandClient-7 | le_atClient.c RxNewData() 653 | read finished
Jun  9 15:35:00 swi-mdm9x28-wp user.debug Legato:  DBUG | atClientDaemon[888]/atClient T=atCommandClient-7 | le_atClient.c RxNewData() 627 | Start read
Jun  9 15:35:00 swi-mdm9x28-wp user.info Legato:  INFO | atClientDaemon[888]/atClient T=atCommandClient-7 | le_dev.c le_dev_Read() 293 | /proc/888/fd/13, /legato/systems/current/appsWriteable/MyApp/dev/ttyHS0 [248, 0], (u: appMyApp, g: ap
Jun  9 15:35:00 swi-mdm9x28-wp user.debug Legato:  DBUG | atClientDaemon[888]/atClient T=atCommandClient-7 | le_dev.c PrintBuffer() 216 | '/legato/systems/current/appsWriteable/MyApp/dev/ttyHS0' -> +INDICATE:0,5,1,13,^Fn^A��^G^D^X	'^B<CR><LF>
Jun  9 15:35:00 swi-mdm9x28-wp user.debug Legato:  DBUG | atClientDaemon[888]/atClient T=atCommandClient-7 | le_atClient.c RxNewData() 643 | Parsing received data: ^M +INDICATE:0,5,1,13,^Fn^A

The le_dev_c PrintBuffer() function reports the correct string. RxNewData() only parses 22 bytes, the rest are all lost. This issue only occurs with this specific command. It also appears it is not due to size, since bigger responses are parsed successfully.

Is there a known issue with characters that are not readable? Could it be something else?

[matt448]

@langestefan I realize I'm responding to a post that is a year old but I recently ran into the exact same problem and thought the info might be helpful to others.

The Problem

The issue with unsolicited messages on the UART's is that the Linux OS is putting the UART interfaces into a suspended state (I'm guessing to save power) and the UART is not ready to receive data. The incoming data does wake up the UART but the first few bytes of data get garbled while the interface is waking up.

I found two solutions for this:

Option 1

If you control the code/firmware of the device sending the unsolicited data you can send two CR+LF's before you send the real data. It's a little clunky but it does work reliably.

\r\n 
\r\n
This is the data I don't want garbled\r\n

Option 2

This option is a little cleaner and works for devices that can't be changed to send the extra CR+LF's. It involves disabling the autosuspend setting for the UART interface.
In the /sys/devices file system there are files that used to configure settings for the UART's. The autosuspend_delay_ms setting is the one we care about. On my system, I have these two:

/sys/devices/platform/msm_serial_hs.0/power/autosuspend_delay_ms
/sys/devices/platform/msm_serial_hs.1/power/autosuspend_delay_ms

The autosuspend_delay_ms option controls how long before the device goes back into suspend mode after going idle. The default is 5000ms (5 seconds). To completely disable autosuspend you write a -1 to this file.
At startup on my system I'm doing this:

echo -1 > /sys/devices/platform/msm_serial_hs.1/power/autosuspend_delay_ms

I spent many, many hours figuring this out. The garbled data made me think there was something wrong electrically but the logic analyzer showed the data was correct on the wire. The kernel docs for USB power management were especially helpful in figuring this out.

Hope this helps someone.