Problem with PPP ending in internal loop

I have come across a rare problem with the PPP / serial drivers.

I use the PPP for a modem (GPRS) connection. A few times I have found customer installations being unable to communicate anymore, even though the outside connection seems OK.

I have found that the device seems to be stuck in some internal loop where it constantly traces (udpdb):

“_uart_check” or “_check_uart”

It is several times / sec. and it is not possible to see which since the come right after each other with no line break.

This is a quite bad situation since we loose connection to the remote devices and the device itselft does not discover the situation. So we need someone to drive to location and power reset the device.

Has anyone come across this problem?

I have been searching for the source of the trace, but I am unable to find the trace anywhere in the source.

Forgot to memtion that the device is using NET+OS 6.3

And I have a clue that it might happen when there is traffic load.

The communication line (GPRS) is relatively slow, so the application can generate messages faster than the line can accept it. Could it be a situation where modem using hardware handshake tries to pause transmission, that is not handled correctly.

A udpdb trace from the device shows this:

ck1uart_check1uart_check1uart_check1uart_check1uart_check1uart_check1uart_check1
uart_check1uart_check1uart_check1uart_check1uart_check1uart_check1uart_check1uar
t_check1uart_check1uart_check1uart_check1uart_check1uart_check1uart_check1uart_c
heck1uart_check1uart_check1uart_check1uart_check1uart_check1uart_check1uart_chec
k1uart_check1uart_check1uart_check1uart_check1uart_check1uart_check1uart_check1u
art_check1uart_check1uart_check1uart_check1uart_check1uart_check1uart_check1uart
_c

So I assume that the trace is really:

“uart_check1”

The PPP connection stopped working and device needs to be rebooted.