[U-Boot] Rx FIFO: more than 64 bytes receive error

[U-Boot] Rx FIFO: more than 64 bytes receive error

[lokesh nijalinge]

Hi,

I am using the arm processor for my project and need to receive around 1K
bytes of data over UART. I am able to receive only 64 bytes at U-boot,
which is the UART RX FIFO size. After receiving the 64 bytes i am not
getting any data. I read the Technical Reference Manual, which says the if
more than FIFO size data is received then data will be lost instead
of overwriting.

Please let me know whether i need to configure any UART registers to
achieve more than 64 bytes.

*Details of the project:*
Processor : DM3730 from Texas instruments -OMAP3 ARM Cortex
UART device : NS16550

The default code having the UART initialization sequence posted below does
not seem to take care of the handling of more than 64 bytes of RX data.

u-boot/drivers/serial/ns16550.c

*Changes done by us to get the Data from RX fifo. *
*
*
Initially with  serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier); we have
not received any data over UART
But after changing the code to  serial_out(0x10, &com_port->ier);
we are receiving the data correctly ,but not more than 64 bytes.
Our goal is to receive 950 bytes.

*
*
*void NS16550_init(NS16550_t com_port, int baud_divisor)*
*{*
*       // serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier);*
*         serial_out(0x10, &com_port->ier);*
*#if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \*
*                                        defined(CONFIG_AM33XX)*
*        serial_out(0x7, &com_port->mdr1);       /* mode select reset
TL16C750*/*
*#endif*
*        serial_out(UART_LCR_BKSE | UART_LCRVAL, (ulong)&com_port->lcr);*
*        serial_out(0, &com_port->dll);*
*        serial_out(0, &com_port->dlm);*
*        serial_out(UART_LCRVAL, &com_port->lcr);*
*        serial_out(UART_MCRVAL, &com_port->mcr);*
*        serial_out(UART_FCRVAL, &com_port->fcr);*
*        serial_out(UART_LCR_BKSE | UART_LCRVAL, &com_port->lcr);*
*        serial_out(baud_divisor & 0xff, &com_port->dll);*
*        serial_out((baud_divisor >> 8) & 0xff, &com_port->dlm);*
*        serial_out(UART_LCRVAL, &com_port->lcr);*
*#if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \*
*                                        defined(CONFIG_AM33XX)*
*
*
*#if defined(CONFIG_APTIX)*
*        /* /13 mode so Aptix 6MHz can hit 115200 */*
*        serial_out(3, &com_port->mdr1);*
*#else*
*        /* /16 is proper to hit 115200 with 48MHz */*
*        serial_out(0, &com_port->mdr1);*
*#endif*
*#endif /* CONFIG_OMAP */*
*}*
*
*
Waiting for your reply.

-- 
Thanks & Regards,
Lokesh Kumar,

[U-Boot] Rx FIFO: more than 64 bytes receive error

[Albert ARIBAUD]

Hi lokesh,

On Sat, 29 Dec 2012 17:01:35 +0530, lokesh nijalinge
<lokesh1kumar2nijalinge@gmail.com> wrote:
> Hi,
> 
> I am using the arm processor for my project and need to receive around 1K
> bytes of data over UART. I am able to receive only 64 bytes at U-boot,
> which is the UART RX FIFO size. After receiving the 64 bytes i am not
> getting any data. I read the Technical Reference Manual, which says the if
> more than FIFO size data is received then data will be lost instead
> of overwriting.
> 
> Please let me know whether i need to configure any UART registers to
> achieve more than 64 bytes.

> *Details of the project:*
> Processor : DM3730 from Texas instruments -OMAP3 ARM Cortex
> UART device : NS16550
> 
> The default code having the UART initialization sequence posted below does
> not seem to take care of the handling of more than 64 bytes of RX data.

Hmm... I can tell any U-Boot receives and correctly processes a lot more
than 64 bytes without any issue; I routinely throw a lot more than this
at the few U-Boot's I have lying around, all of which use NS16550-like
serials. I even sometimes 'loads' a payload of several hundred bytes to
some megs, without any issue.

However, while 'loads' itself can handle very large serial input, the
serial driver in itself will never handle more than the FIFO depth:
the 'loads' command handler has to read from the driver frequently in
order to avoid an overload.

In your case, you did not describe (or did I miss it?) what it is that
*uses* the received bytes, and how and when these received bytes are
read from the driver. Can you elaborate on this?

> *Changes done by us to get the Data from RX fifo. *

Please show such changes as a patch (made with got format-patch or at
least git diff) -- with '[RFC]' in the message subject so that we know
it is not a submission for inclusion into U-boot.

Amicalement,
-- 
Albert.

[U-Boot] Rx FIFO: more than 64 bytes receive error

[lokesh nijalinge]

Hi ,

Thank you very much ,for the quick response albert

The detailed explanation about the project is as below:

I have a fingerprint module(FPC-AM3) which works fine and can receive whole
fingerprint template data at kernel on UART2 of the processor. The same i
am trying to implement at u-boot. I am trying to receive almost 1Kb of
fingerprint template.

Fingerprint template is received once we transmit a command of 6 bytes to
fingerprint over UART2 to Fingerprint module, and then the response is 948
bytes of template data over UART2 on the Receive side.

I went through the "*loads*" command too. If i am not wrong it takes the
file from remote location and loads on to the address mentioned in the
argument, which is not the idea. As explained before we are trying to
receive 948 bytes of data from the UART2 port (Fingerprint module).

Attaching the patch as suggested  :patch includes our finger print code and
the UART2 initialization change.

Please help us in getting the 948 bytes of data over UART2. Let us know the
code changes.

*NOTE: we have even modified the hardware for a loopback connection and
then ran the same code on it, but we could not receive more than 64 bytes.
We are receiving the first 64 bytes and then rest of the bytes are not seen.
*



Thanks & Regards,
Lokesh


On Sat, Dec 29, 2012 at 7:28 PM, Albert ARIBAUD
<albert.u.boot@aribaud.net>wrote:

> Hi lokesh,
>
> On Sat, 29 Dec 2012 17:01:35 +0530, lokesh nijalinge
> <lokesh1kumar2nijalinge@gmail.com> wrote:
> > Hi,
> >
> > I am using the arm processor for my project and need to receive around 1K
> > bytes of data over UART. I am able to receive only 64 bytes at U-boot,
> > which is the UART RX FIFO size. After receiving the 64 bytes i am not
> > getting any data. I read the Technical Reference Manual, which says the
> if
> > more than FIFO size data is received then data will be lost instead
> > of overwriting.
> >
> > Please let me know whether i need to configure any UART registers to
> > achieve more than 64 bytes.
>
> > *Details of the project:*
> > Processor : DM3730 from Texas instruments -OMAP3 ARM Cortex
> > UART device : NS16550
> >
> > The default code having the UART initialization sequence posted below
> does
> > not seem to take care of the handling of more than 64 bytes of RX data.
>
> Hmm... I can tell any U-Boot receives and correctly processes a lot more
> than 64 bytes without any issue; I routinely throw a lot more than this
> at the few U-Boot's I have lying around, all of which use NS16550-like
> serials. I even sometimes 'loads' a payload of several hundred bytes to
> some megs, without any issue.
>
> However, while 'loads' itself can handle very large serial input, the
> serial driver in itself will never handle more than the FIFO depth:
> the 'loads' command handler has to read from the driver frequently in
> order to avoid an overload.
>
> In your case, you did not describe (or did I miss it?) what it is that
> *uses* the received bytes, and how and when these received bytes are
> read from the driver. Can you elaborate on this?
>
> > *Changes done by us to get the Data from RX fifo. *
>
> Please show such changes as a patch (made with got format-patch or at
> least git diff) -- with '[RFC]' in the message subject so that we know
> it is not a submission for inclusion into U-boot.
>
> Amicalement,
> --
> Albert.
>



-- 
Thanks & Regards,
Lokesh Kumar,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: custom_patch.patch
Type: application/octet-stream
Size: 25209 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121231/56cfd65f/attachment.obj>

[U-Boot] Rx FIFO: more than 64 bytes receive error

[Albert ARIBAUD]

Hi lokesh,

On Mon, 31 Dec 2012 14:59:36 +0530, lokesh nijalinge
<lokesh1kumar2nijalinge@gmail.com> wrote:
> Hi ,
> 
> Thank you very much ,for the quick response albert
> 
> The detailed explanation about the project is as below:
> 
> I have a fingerprint module(FPC-AM3) which works fine and can receive whole
> fingerprint template data at kernel on UART2 of the processor. The same i
> am trying to implement at u-boot. I am trying to receive almost 1Kb of
> fingerprint template.
> 
> Fingerprint template is received once we transmit a command of 6 bytes to
> fingerprint over UART2 to Fingerprint module, and then the response is 948
> bytes of template data over UART2 on the Receive side.
> 
> I went through the "*loads*" command too. If i am not wrong it takes the
> file from remote location and loads on to the address mentioned in the
> argument, which is not the idea. As explained before we are trying to
> receive 948 bytes of data from the UART2 port (Fingerprint module).

I mentioned 'loads', not to suggest a workaround, but to point you to
a case where large quantities of data can be read at the client level
despite the driver level only processing small quantities.

> Attaching the patch as suggested  :patch includes our finger print code and
> the UART2 initialization change.

Please do not send patches to the list unless you intend them for
inclusion into mainline U-Boot; or at least tag the mail subject "RFC"
so that we know it is only posted for comments, and then, post them
using 'git format-patch' and 'git send-email'.

> Please help us in getting the 948 bytes of data over UART2. Let us know the
> code changes.
> 
> *NOTE: we have even modified the hardware for a loopback connection and
> then ran the same code on it, but we could not receive more than 64 bytes.
> We are receiving the first 64 bytes and then rest of the bytes are not seen.
> *

This patch contains code outside the mainline tree, and I suspect there
is more non-mainline code in your tree, as for instance your version
of NS16550_getc() seems to be able to return on time-out, which
the mainline NS16550_getc() does not do AFAIK.

You are thus the only person on this list who has both the full source
code and the relevant hardware, hence the only person able to debug it.
I suggest placing hardware breakpoints on code executed upon time-out
condition to begin with.

Amicalement,
-- 
Albert.