Nucleus PLUS sdc.c usart tx buffer seems always full

We have a case where we 1) some times loose send character on the
usart and now 2) Nucleus _always_ sees a full tx buffer  (after
sending a "random" number of characters first - several KB) and does a
NU_Sleep(1) in a loop forever. This seems to hog the machine. We have
sdc.c version "Nucleus PLUS\Integrator\RVCT 1.15.17" and run on  for
ARM9.

If this is,a s I presume, an sdc.c error - does anybody have a fix for
this?

It seems like the TX interrupt has been switched off, or a skew or a
glitch in the code may have handled the "while (uart->tx_buffer_write
=3D=3D uart->tx_buffer_read)" idices incorrectly. They never change.

=D8yvind Teig
Autronica Fire and Security AS
A UTC Fire & Security Company
http://home.no.net/oyvteig/work/work.html

Comment from the inititator of this thread:

If I add a cnt, so that our Nucleus task does not any more block on
full TX buffer, brute force like this, then..
/* If the buffer is full wait for it to empty a little. */
UINT8 cnt=3D0; // oyviteig
while ((uart->tx_buffer_write =3D=3D uart->tx_buffer_read) && (cnt<2))
{
   /* Restore interrupts to previous level */
   NU_Local_Control_Interrupts(int_level);
   //temp_byte ++;
   NU_Sleep(10); // instead of 1
   cnt++;
}
if (cnt=3D=3D2)
{
    NU_Local_Control_Interrupts(int_level);
    uart->tx_buffer_read =3D uart->tx_buffer_write =3D 0;
    uart->tx_buffer_status =3D NU_BUFFER_EMPTY;
}

.=2Eit goes on - and all works except I loose a full buffer. But since
resetting the read and write indices help, it looks like there is a
probem with them - since on next round the usart sends characters.


On 14 Jun, 13:24, aclassifier <oyvind.t...@autronicafire.no> wrote:
> We have a case where we 1) some times loose send character on the
> usart and now 2) Nucleus _always_ sees a full tx buffer  (after
> sending a "random" number of characters first - several KB) and does a
> NU_Sleep(1) in a loop forever. This seems to hog the machine. We have
> sdc.c version "Nucleus PLUS\Integrator\RVCT 1.15.17" and run on  for
> ARM9.
>
> If this is,a s I presume, an sdc.c error - does anybody have a fix for
> this?
>
> It seems like the TX interrupt has been switched off, or a skew or a
> glitch in the code may have handled the "while (uart->tx_buffer_write
> =3D=3D uart->tx_buffer_read)" idices incorrectly. They never change.
>
> =D8yvind Teig
> Autronica Fire and Security AS
> A UTC Fire & Security Companyhttp://home.no.net/oyvteig/work/work.html

I received this mail from a user in NL, and have been allowed to post
it.It is an important list to keep in mind when we must indeed check
all this - if new code does not appear from someone who reckognise our
case (to save time for us).

-- User reply --
Case of classical data sharing between interrupt code and task code?
Several things you should check:
1) Updates of shared variables in task code should happen with
interrupts  temporarily disabled.
2) Ideally task only updates read pointer and interrupt should only
update write pointer.
Decide when to lose characters (buffer==full and new character
arrives)
3) Shared variables must be declared with volatile qualifier.