Greetings,
In my application I am using RXRDY* to trigger unloading of the receive FIFOs. No interrupts on the part are enabled (or connected). The original implementation included a 4800 baud data stream being applied to the part during reset and initialization. *Sometimes*, upon completion of initialization, RXRDY* would only be asserted a single time and after returning to the de-asserted state would stay there regardless of the continuous data stream being applied to the chip. On other occasions (about 50% of the time) it would respond as expected and the data stream would be received (and read by the processor) as intended.
Uninformed work-around: Although I have not determined the details or reasons for this behavior, I have determined that if I implement both of the following (neither, by itself is sufficient) the problem behavior does not occur.
1- Force all the receive lines into the idle state during reset and initialization.
2- Use a timeout so that if the application waits too long, at startup, for expected data (from a FIFO that sits between the interrupt routine and the application) to force reading from the receive fifos on the chip (bypassing the int routine) until they are empty.
What I have found with these work-arounds is that some of the time, 2- will have data to empty even though RXRDY* is not asserted and after emptying the FIFO RXRDY* resumes normal operation.
I have also observed that if 1- is not implemented, 2- will continue to have data to empty and the expected behavior of RXRDY* never occurs.
I would like a better work around (or correction to my init etc.), if available, as 1- requires board rework I would like to avoid. I would also like a better understanding of what I going on so that I can have high assurance that my eventual implementation is bullet proof in this area.
All my indications are that once RXRDY* starts running as expected (i.e. it asserts after initialization more that just once) it will continue to work as expected.
My init code is below. For my work so far, only the GPS connection is implemented. Thanks for any and all insights!
Steve.
/* Init of UARTS first */
//Write special "key" code into LCR (0xBF) to enable access to the EFR, Xon/Xoff, DLL
//and DLH registers. (available registers now: DLL, DLH, EFR, Xon-1, Xon-2, Xoff-1, Xoff-2)
cellUart[UART_LCR] = 0xBF;
gpsUart[UART_LCR] = 0xBF;
sonicUart[UART_LCR] = 0xBF;
valveUart[UART_LCR] = 0xBF;
//Write ^Q (0x11) into Xon-1 and ^S (0x13) into Xoff-1
cellUart[UART_Xon1] = 0x11;
gpsUart[UART_Xon1] = 0x11;
sonicUart[UART_Xon1] = 0x11;
valveUart[UART_Xon1] = 0x11;
cellUart[UART_Xoff1] = 0x13;
gpsUart[UART_Xoff1] = 0x13;
sonicUart[UART_Xoff1] = 0x13;
valveUart[UART_Xoff1] = 0x13;
//Write 0x00 into DLH and 0x18 into DLL to set baud rate to 9600 (default) except for GPS which is 4800.
cellUart[UART_DLH] = hBaudByte(cpot.cell_baud);
gpsUart[UART_DLH] = hBaudByte(cpot.gps_baud);
sonicUart[UART_DLH] = hBaudByte(cpot.sonic_baud);
valveUart[UART_DLH] = hBaudByte(cpot.valve_baud);
cellUart[UART_DLL] = lBaudByte(cpot.cell_baud);;
gpsUart[UART_DLL] = lBaudByte(cpot.gps_baud);
sonicUart[UART_DLL] = lBaudByte(cpot.sonic_baud);
valveUart[UART_DLL] = lBaudByte(cpot.valve_baud);
//Write 0x10 into the EFR to enable access to enhanced feature bits in EIR 4-7, FCR 4-5 and MCR 5-7
//(or write 0x1A to also enable "software" flow control as implemented in the controller
// but only after flow contrl trigger levels are set below in the TCR)
cellUart[UART_EFR] = 0x10;
gpsUart[UART_EFR] = 0x10;
sonicUart[UART_EFR] = 0x10;
valveUart[UART_EFR] = 0x10;
//Write0x03 into LCR to set 8bit, no parity and one stop bit AND to re-enable access to MCR
//(available registers now: RHR/THR, IER, IIR/FCR,LCR, MCR, LSR, MSR, SPR)
cellUart[UART_LCR] = 0x03;
gpsUart[UART_LCR] = 0x03;
sonicUart[UART_LCR] = 0x03;
valveUart[UART_LCR] = 0x03;
//Write 0x40 into MCR to enable access to TCR and TLR (instead of FifoRdy)
//(available registers now: RHR/THR, IER, IIR/FCR,LCR, MCR, LSR, TCR, TLR)
cellUart[UART_MCR] = 0x40;
gpsUart[UART_MCR] = 0x40;
sonicUart[UART_MCR] = 0x40;
valveUart[UART_MCR] = 0x40;
//Write 0x8F into TCR to set recieve flow control trigger levels of 60 chars (halt) and 32
//chars (resume)
cellUart[UART_TCR] = 0x8F;
gpsUart[UART_TCR] = 0x8F;
sonicUart[UART_TCR] = 0x8F;
valveUart[UART_TCR] = 0x8F;
//Write 0x88 into TLR to set DMA (i.e. interrrupt in this application) trigger levels of 32 chars
//for both Rx and Tx - Note: if these values are changed, the #defines, above, for CellComBlkSize,
// etc. need to be updated.
cellUart[UART_TLR] = 0x88;
gpsUart[UART_TLR] = 0x88;
sonicUart[UART_TLR] = 0x88;
valveUart[UART_TLR] = 0x88;
//Write 0x04 into MCR to enable access to FifoRdy (instead of TCR and TLR)
//(available registers now: RHR/THR, IER, IIR/FCR,LCR, MCR, LSR, MSR, FifoRdy)
//NOTE: IRQ outputs not used except for debug - I've left them on, writing 04
//instead of 0C will turn them off
cellUart[UART_MCR] = 0x04;
gpsUart[UART_MCR] = 0x04;
sonicUart[UART_MCR] = 0x04;
valveUart[UART_MCR] = 0x04;
//Write 0xA9 into FCR to set RX fifo trigger level to 56 chars, TX fifo trigger level to 32 chars,
//NOTE: these trigger levels are over-ridden by those defined in the TLR
//DMA Mode 1 and Enable both RX and TX fifos. And reset them (0xA9 -> 0xAF to reset).
cellUart[UART_FCR] = 0xAF;
gpsUart[UART_FCR] = 0xAF;
sonicUart[UART_FCR] = 0xAF;
valveUart[UART_FCR] = 0xAF;
