Multiple serial port misbehavior

[Altera_Forum]

Quartus 4.1, Nios1.01: 

 The NiosII system has 2 uarts, a primary debug terminal@115K baud, and a secondary half-duplex slave device@19.2K baud.  During operation lots of printf output (from many uCos tasks) goes out to the terminal (a PC running hyperterm) to be logged. There is no input on this uart.  A dedicated task talks to a 2nd serial slave device. You send this device a short ascii string, and it returns 100 or so ascii chars terminated with cr.   When tested directly with hyperterm, the device works OK.   When tested on the NiosII system, I am losing chars both on input and output for the 2nd uart.   There appears to be a dependancy between the uarts such that as long as the primary uart is sending out chars, the secondary uart is getting partially or fully blocked. Changing the uart assignments ie. 1st uart is for slave device, 2nd uart is for terminal, did not fix the lost char issue with the slave device. Currently I am using fopen(),fgetc(), fputc() for this uart, and will try switching to open(),read(),write() to see if it makes a difference.  Any ideas?  thanks

[Altera_Forum]

for a test try to set the ring buffer size in avalon_uart.h to more than 64 (e.g. 2048) 

we also use 2 uarts and we open the uart twice (non blocked for input and blocked for output).

[Altera_Forum]

Which set of functions are you using, the fopen(),fread(),fwrite() or the open(),read(),write() ? 

As I understand it, the fopen(),etc does thread-safe checking and would have more overhead than the open(),etc.  Increasing the buffer size is a great idea - but I had the impression from the program behavior that there already was a large print buffer for printf(). The reason I say that is the a multi-task app which generates a lot of output from several tasks, I never see interleaved print output. A 64 char buffer would fill up fast. I'd expect to see either interleaved print output or lost chars on my main terminal. I don't see this.

[Altera_Forum]

The larger buffer did not change things. I did discover something unusual. My 2nd uart, the one with problems, will spit out an 'E' shortly after I send out a command string. There is no place in the code that would write this char to the uart, and I have specifically placed a filter to catch it. Either the uart driver is adding this 'E', or the uart itself is somehow generating it. Bizarre.

[Altera_Forum]

Are you using (or needing to use) hardware handshake? Does the UART indicate Rx overrun? If the device is talking to a PC, make sure the Tx FIFO is set to 1.

[Altera_Forum]

No HW handshake. The uarts are minimal implementations. I have increased the uart driver buffer size to 1K. I don't see any TX FIFO option. Does this dialog appear when you enable HW handshake? 

 The traffic on my 2nd uart is small. I send out 12 chars every 10secs or so, and I get a response of about 130 chars. Tx and Rx on this uart is 19200.

[Altera_Forum]

Fixed it.  

The problem was accessing using the same r/w file ptr from two different async tasks. Incomming data was getting mixed with outgoing data within the low-level file management block. Fischer's suggestion of opening the file twice seems to be the cleanest solution. With fread(),fwrite(), no further exclusion or synchronization appears needed.