cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 5, 3 & 1 MCU

Dudi_Ildis
New Contributor II

We are using the UART with the HW fifo of 4, we find that when disabling interrupts for long time (not for 4 fifo long), we start to loss bytes sometimes (for our opinion the HW fifo not works OK).

Here is our interrupt handler that we used for testing:

CY_ISR(drvUART_A_RxISR)
{
uint8 dataByte, statusByte;
uint16 receivedData;
uAmaxrcv=0;
do{
  receivedData = UART_A_GetByte();
 
dataA[k] = receivedData;
  k = (k+1)%BLEN_TEST;
 
dataByte = (uint8)(receivedData & 0x00FFu);
 
 statusByte = (uint8)((receivedData & 0xFF00u) >> 8u);
 
if((statusByte & UART_A_RX_STS_FIFO_NOTEMPTY) != 0u){
          if((statusByte & (UART_A_RX_STS_BREAK | UART_A_RX_STS_PAR_ERROR |
               
UART_A_RX_STS_STOP_ERROR | UART_A_RX_STS_OVERRUN)) != 0u){
                g_drvUART_driverStatus.uart_rxStatusErr[DRV_UART_MODULE_A]++;
    
}
         else{
              drvUART_fifoPushByte(DRV_UART_RX_FIFO_A, dataByte);
     
uAmaxrcv++;
        }
    }
}while((statusByte & UART_B_RX_STS_FIFO_NOTEMPTY) != 0u);
if (uAmaxrcv > uAprevmaxrcv){
     uAprevmaxrcv=uAmaxrcv;
}
}

What we have seen that when we care disabling the interrupt for short time (not more than 1 byte in 4 bytes HW fifo) we are not loosing bytes, but when we are increasing the time of disale interrupt (global interrupt) we start to loose bytes even when 'uAprevmaxrcv'  is 2.
Thanks for any help,

Dudi

 

0 Likes
8 Replies
BiBi_1928986
Valued Contributor

Hello.

Just an observation...
The do{...} while(...) is checking UART_B status.
Shouldn't it be checking UART_A status in the while(...) test?

0 Likes
Dudi_Ildis
New Contributor II

receivedData = UART_A_GetByte();

This function returns Uint16 when the upper byte is the status and lower is the data....
You are right that I'm using UART_B_RX_STS_FIFO_NOTEMPTY in the checking but it is the same constant for A (5) (copy paste issue but doesn't affect the running (:))

 

0 Likes
BiBi_1928986
Valued Contributor

Hello.

I assume uAprevmaxrcv is modified somewhere in main.c.
If this variable is used in both main and ISR, do you disable/enable interrupts when main modifies uAprevmaxrcv?

BTW, how do you measure global interrupts are  only disabled for lessthan 1 serial byte time?  Toggling a port pin and observing on oscilloscope?

0 Likes
shinsakka
New Contributor II

Same observation, verified this UART behavior some time ago by single-byte transfers (filling up the UART FIFO) and outputing the signals to a scope.

Cf. https://community.cypress.com/t5/PSoC-Creator-Designer-Software/UART-FIFO-psoc-5/m-p/274562/highligh...

0 Likes
Dudi_Ildis
New Contributor II

Its seems to be my problem, do anyone know if there is new version of UART from cypress that solve the problem?

0 Likes
shinsakka
New Contributor II

Not that I know of (at least not for the PSoC 5LP).

I discovered the bug a few years ago, and nothing has changed since then. My impression is that Cypress is not actively developing/updating components for the PSoC 5LP. I didn't file a bug report, since it's quite tedious and time-consuming nowadays to escalate the report to someone who actually understands it. Whether and when it results in a bugfix - who knows. I told them about wrong data in the SAR ADC datasheet, and although they acknowledged it and promised to change it in the "next datasheet" nothing has changed since then. In that respect Cypress' service and the quality of the Creator environment/components/datasheets is surprisingly lacking... <end of whining>

What can you do? Repair the component yourself. Unless someone from Cypress chimes in and allows me to upload their modified component source code, I can only explain how to do it yourself (don't have time & knowledge to check what their licenses allows me to do, sorry for that ).

Dudi_Ildis
New Contributor II

Thanks for your detailed clear answer, since I'm SW eng. not familier with verilog I'll ask our HW engineer if we can do the change. Meantime we solve this problem by changing our code to disable the interrupt for very short time, which cause not using the HW FIFO....

Regards,

Dudi

0 Likes
shinsakka
New Contributor II

Apart from the underlying UART problem, you might wanna reevaluate your interrupt priorities.

Instead of brute-force disabling all interrupts for a long period of time, you might be better off disabling just interrupts below a certain priority and put the UART Rx interrupt above it, thus ensuring that the Rx ISR is triggered sufficiently frequently...

0 Likes