EzBe,
Sorry for my lengthy post today.
As I indicated, my results cannot replicate yours. This is probably because my timing on reading the UART FIFO and the new data being input into the FIFO is not accurate enough.
Here is some debugging ideas that will help me (and others) to replicate what you are seeing.
The following recommendations require an oscilloscope or logic analyzer to display the signals and they're timing relationship.
Create a HW signal when the Rx byte is received
You already have the UART configured as "Advanced/Interrupt Sources/RX - On Byte Received" set ONLY.
Attach a digital output pin to the UART's rx_interrupt output. (See pic)
This will be the signal reference when the new byte is actually received. It will be HW-dependent and not SW-dependent. Therefore the timing relationship will be extremely accurate.
Create a HW signal when the Rx byte is read from the FIFO.
Allocate another digital output pin. (See pic)
This output is used to frame the SW read of the FIFO byte.
In your code that reads the FIFO byte:
while(((UART_2_ReadRxStatus()&UART_2_RX_STS_FIFO_NOTEMPTY)>0)&&(received_bytes<24))
{
n= UART_2_ReadRxData(); //GetByte
pll_data_receive[received_bytes]=n;
received_bytes++;
}
Change to:
while(((UART_2_ReadRxStatus()&UART_2_RX_STS_FIFO_NOTEMPTY)>0)&&(received_bytes<24))
{
Read_FIFO_byte_frm_Write(1); // turn on the frame
n= UART_2_ReadRxData(); //GetByte
Read_FIFO_byte_frm_Write(0); // turn off the frame
pll_data_receive[received_bytes]=n;
received_bytes++;
}This signal is a combination of HW and SW dependent. It is HW because it frames the ReadRxData() function but since it is in code, it can be pre-empted by other events such as other interrupts or DMA (if you have that turned on).
Create a HW signal for when the Data Error occurs
Allocate another digital output pin. (See pic)
This is a SW-dependent signal that flags to the outside world that a data error occurred.
In your modified code that reads the FIFO byte:
while(((UART_2_ReadRxStatus()&UART_2_RX_STS_FIFO_NOTEMPTY)>0)&&(received_bytes<24))
{
Read_FIFO_byte_frm_Write(1); // turn on the frame
n= UART_2_ReadRxData(); //GetByte
Read_FIFO_byte_frm_Write(0); // turn off the frame
/* Analyze if a data error occurred */
if(... code that determines an error occurred ...)
{
Data_ERROR_Write(1); // turn on the frame
Data_ERROR_Write(0); // turn off the frame
}
pll_data_receive[received_bytes]=n;
received_bytes++;
}
Analysis Phase
Now that you have the three HW signals on an oscilloscope or logic analyzer, look for when the Data_ERROR signal is valid (you can probably trigger on that event) and now you should have the timing relationship that occurs when the new byte is received into the FIFO and when the FIFO read occurs.
If you share these results with me (or the forum) others will have a much better time to replicate your results.
ezbe,
I've provided a first pass at a potential reason and solution.
Hopefully it helps.
I've taken another closer look at your revD doc. I have a few observations.
Observation1
You list: Software (inside of isr_1):
The while() loop (as well as do()) is very 'dangerous' inside an ISR. The general rule-of-thumb for ISRs is to "get in and get out quickly". ISR are intended to service the immediate needs of an event. In the case of isr_1 it is the 30Hz 'tick'.
Avoid using blocking functions (CyDelay() is terrible) or blocking code such as while() and do(). The while() loop is time-indeterminate. There is NO guarantee that the conditions to satisfy the while() will occur in a timely manner. You could be stuck in isr_1 for a long time and the other interrupt tasks and main() may not be serviced properly.
Recommendation: In the isr_1 which is the 30Hz tick, create a flag in RAM: _Bool tick_30Hz. In the isr_1, set
tick_30Hz = 1; In the main() task
while(tick_30Hz == 1)
{ /* The 30Hz tick occurred */
tick_30Hz = 0; /* reset the flag */
/* place your code here to process the 30 Hz tick */
}
... /* go do other things as needed */
Observation2
It appears you are potentially using ALL the bytes of the 4-byte FIFO.
The FIFO is intended to buffer in case the CPU is experiencing latencies in getting to the data. As a general rule, it is best to code as if you don't have a FIFO.
Recommendation: If you don't already have one, create a UART_RX_isr component and place it on the UART_2 rx_interrupt pin.
In the isr code for this interrupt (let's call it isr_UART_RX), allocate enough buffer data in RAM needed for the 30Hz tick to process.
In the isr_UART_RX() for every byte you receive, store it in the RAM Rx buffer and increment a variable called rx_idx. The rx_idx > 0 can signal the 30Hz tick task that data is available. This is ALL the UART_RX_isr does. Short and sweet.
uint8 rx_buffer[4]; /* 4 bytes in the buffer */
_Bool rx_idx=0; /* rx buffer count idx */
CY_ISR(UART_RX_isr)
{
rx_buffer[rx_idx] = UART_2_ReadRxData();
rx_idx++;
}In the main() task that processes the 30Hz tick subtask, check for tick_30Hz flag (see code frags above). If set, process all the data (as indicated by buffer_idx) in the RAM Rx buffer. Lastly before exiting the 30Hz tick subtask, you need to do cleanup.
while(tick_30Hz == 1)
{ /* The 30Hz tick occurred */
tick_30Hz = 0; /* reset the flag */
/* place your code here to process the 30 Hz tick */
... /* process the Rx Buffer data as needed */
/* Lastly do cleanup */
UART_DisableRxInt() /* Temporarily disable the UART_Rx interrupt during the cleanup */
rx_idx = 0; /* reset the Rx buffer index */
UART_EnableRxInt() /* re-enable the UART_Rx interrupt */
}
... /* go do other things as needed */
