Author Topic: Serial data are lost..  (Read 7867 times)

Offline svl

  • Jr. Member
  • **
  • Posts: 52
    • View Profile
Serial data are lost..
« on: December 11, 2008, 12:29:18 PM »
Hi Mark

I am trying to make a TCP to RS-232 gateway.
I have a been using some of the examples from this forum and the changed a bit...

It all looks perfect when testing the gateway, but when i try to use the FTP or HTTP server data is lost.

After tracking this problem a bit I found that it actually are data from the RS-232 port that are missing.
The set up of the serial ports are like this:
Code: [Select]
    tInterfaceParameters.Channel = i;                            // set UART channel for serial use
    tInterfaceParameters.ucSpeed = SERIAL_BAUD_9600; // baud rate
    tInterfaceParameters.Rx_tx_sizes.RxQueueSize = RX_BUFFER_SIZE;       // input buffer size
    tInterfaceParameters.Rx_tx_sizes.TxQueueSize = TX_BUFFER_SIZE;       // output buffer size
    tInterfaceParameters.usConfig = (CHAR_8 + NO_PARITY + ONE_STOP + CHAR_MODE);
    tInterfaceParameters.Task_to_wake = OWN_TASK;                        // wake self when messages have been received
   
    if ((ucGateway[i].SerialPortID = fnOpen( TYPE_TTY, FOR_I_O, &tInterfaceParameters )) != 0) { // open or change the channel with defined configurations (initially inactive)
        fnDriver( ucGateway[i].SerialPortID, ( TX_ON | RX_ON ), 0 );                  // enable rx and tx
    }

As you can see the speed of the serial communication are low so I expect that data are lost some ware between the RX buffer and the task that are handling my application.

Do you have any suggestions

Regards Steen

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Serial data are lost..
« Reply #1 on: December 11, 2008, 10:16:01 PM »
Hi Steen

In which direction is the data being lost (RS232 Tx or RS232 Rx?)

Is the loss a loss of a block of data (eg. a number of characters in a sequence) or individual characters?

Have you some debug output messages operating at the same time (I ask because I heard that such a problem once stopped when debug messages were deactivated and this is something that I plan to look in to).

Regards

Mark

Offline svl

  • Jr. Member
  • **
  • Posts: 52
    • View Profile
Re: Serial data are lost..
« Reply #2 on: December 15, 2008, 09:24:26 AM »
hi mark

In which direction is the data being lost (RS232 Tx or RS232 Rx?)

The data are lost in the RS232 Rx direction only.

When I send e.g. "o---- Ping", 2 or 3 byte in the middle of the data are missing.

I do not transmit any debug data while this is happening.

I have tried to use DMA on the serial port, but then I was receiving no data at all. (Properly be course I was doing something wrong  ;) )

In my eyes it looks like an interrupt that are not handled and therefore data are lost. But I have no ideas on how to prow this theory? 

Hope you can push me in the right direction?

Regards
Steen

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Serial data are lost..
« Reply #3 on: December 15, 2008, 10:55:11 AM »
Hi Steen

DMA on reception is only useful when the frame size is fixed or receive frames terminated by a break condition, or similar, due to the fact that the DMA reception needs to know when it is complete before terminating. Generally when activated it will be set up to receive half the rx buffer length and then wake the handling task. If you don't receive so many characters in your test it has probably stored them in the input buffer but not yet reported that they are there. See the following for more details: http://www.utasker.com/forum/index.php?topic=140.0

In order to lose interrupts it would require interrupts to be blocked for longer than 2 character intervals. At 9600 baud this is about 2.3ms. An overrun would result and thus characters be lost.

To debug this, the following method could be used (assuming UART 0).
1. In _SCI0_Interrupt() an overrun can be detected by adding if (USR_UCSR_0 & (UART_OE)) {. A spare post can be set high when this happens and used to trigger an oscilloscope.
2. To monitor blocking interrupts the following can be added to the routines uDisable_Interrupt() and uEnable_Interrupt()

- at the end of uDisable_Interrupt() set a free test port output high
- in uEnable_Interrupt, when the value of iInterruptLevel reaches zero, set the port output back low.

When the overrun output triggers you can then see whether the interrupts have really been blocked for a long period of time (> 2.3ms) prior it it happening. If this is the case you will then need to find out what is calling the disable interrupt but not setting it back for so long.

As reference: I recently did tests at 115k baud tx and rx with intensive web server use at the same time. The results showed that a rx interrupt is handled every 88us and lasts about 6,8us. Maximum jitter detected was about 20us (that is the delay to handling a UART interrupt due to other interrupts and/or blocked interrupt periods).

Where potential problems can exist is when FLASH memory is being modified (deleted, written) due to the fact that all interrupt processing has to be stopped while the FLASH is working. Check whether something may be stored in FLASH during the test!

regards

Mark