4 Replies Latest reply on Jan 10, 2014 6:22 AM by HeLi_263931

    Problem with UART transmit


      Hello. I am developing using Psoc 5. One of the things I need to do is repeatedly measure an A/D voltage and send the results over the serial RS232 line to a PC. Each transmission is 22 bytes and they are sent as fast as the processor can take an A/D reading.


      Something strange is happening. It will send the value 276 times and then fail. The way it fails is that it starts a new transmission before the previous one has completed. It seems to be a buffer overflow problem but I have not found any method to correct the problem. However if I slow down the transmission frequency (for instance by taking each A/D reading 20 times and averaging) then the problem is not seen.


      I started out using a TX buffer of 256 bytes. As a test I reduced TX buffer to 4 bytes, thinking that the problem might be in the interrupt routine. It made absolutely no difference. I am running RS232 ad 115 kBaud and I have added code to protect against buffer overflow (that code was disabled during the 4 byte tx buffer test). Each time I send the 22 byte data, I use the following code:




         SendSerial (buf, len);   // send 8 bytes
          SendSerial (((char*) &IRd, sizeof (ImRetData));  // send 22 bytes


      The SendSerial routine looks like this:


      Void SendSerial (char *buf, int len)
          WaitForUartTxBufEmpty (200);


          UART_PutArray ((BYTE*) buf, len);


      void WaitForUartTxBufEmpty (int len)
          while (UART_GetTxBufferSize () > len);


      Originally I had a timeout in the wait for empty routine, but removed it during testing to be sure it was not timing out. I have also tried changing the wait routine input length to zero.


      I really think the problem is in the wait routine. I suspect that the routine returns before the buffer is empty, but debugging is difficult on this device. For instance it seems impossible to set debug conditions. If there is a way I would appreciate the info.


      Thank you, Russ