This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UART3 RX not working

UART3 interrupt handler is not receiving the complete string
There is a string of 43bytes send to UART3 of ARM LPC2378
UART3 handler is Rxing only first 16bytes properly and immediately afterwords it reads last 5bytes of the string. Rest of the (middle)characters are not read.
Why is not reading all the 43characters in order.

char UART3_init(void) { PCONP |= 0x03401000; PINSEL0 |= 0x0000000A; /* Enable TxD3 RxD3 P0.0 & P0.1 Respectively */ U3IER = 0;

U3FDR = 0; U3LCR = 0x83; U3DLL = 78; U3DLM = 0x00; U3LCR = 0x03; U3FCR = 0x07;

if ( install_irq( UART3_INT, (void *)UART3Handler, SEC_PRIORITY ) == FALSE ) { return (FALSE); }

U3IER = IER_RBR | IER_THRE | IER_RLS; /* Enable UART3 interrupt */ return (TRUE); }

Parents
  • 1) Don't you like comments? You think it is good with magical values in the code? It is only 0x04 and 0x0C you seem to have documented - and these two comments seems to be a copy/paste from reference code.

    2) You have problems with buffer overruns - or at least with lost characters. But you still don't care about the OE (Overrun Error) bit in the LSR (Line Status Register). Aren't you interested if this bit is set or not? You think it would give you too much hints what is wrong if you find this bit set?

    3) If your receive buffer goes full for some reason, you just zero the character counter without somehow setting any flag or in any other way inform your program that this have happened. Why not? Don't like debug help like that?

    4) You have a "default" in your switch statement that doesn't do anything - but the code after the switch statement is written based on the assumption that you always have received a character. Remember that your init code did turn on IER_THRE which mean the processor wants to create an interrupt to full the UART with outgoing data too - something your interrupt handler doesn't support.

    5) You have code like:

    U3IER = IER_RBR | IER_RLS;      // Re-enable receive interrupt
    

    So are there other code sections somewhere that disables the receive interrupt?

    6) You have a main loop containing:

    for(i=0;i<47;i++)
    


    But where have you maked sure that the received message really has that size? Do you just assume it, just because you assume that is the size the sending side would send? Anyone ever told you assumptions are bad, and tends to hurt?

    7) I don't see that you have any code in your ISR that tries to count how many characters you manage to pick up in a single interrupt - which would have been interesting information given that the receive FIFO have a limited size and debuging of your code should show that you are always way faster reading out data than what data comes in.

    8) You have local variables inside your ISR that is declared volatile - why? You understand the meaning of the volatile keyword? So then tell me why you think you need it for your local variables.

    9) How can you be sure that the UART doesn't receive the first characters of the next message before your main loop have had time to print the full set of characters from the previous message? Your ISR doesn't look at the flag.EOL_PC flag to verify if the buffer is free to be filled with new data.

    There are probably other issues hidden there too, but above should be enough for you to start actually doing a bit of debugging.

Reply
  • 1) Don't you like comments? You think it is good with magical values in the code? It is only 0x04 and 0x0C you seem to have documented - and these two comments seems to be a copy/paste from reference code.

    2) You have problems with buffer overruns - or at least with lost characters. But you still don't care about the OE (Overrun Error) bit in the LSR (Line Status Register). Aren't you interested if this bit is set or not? You think it would give you too much hints what is wrong if you find this bit set?

    3) If your receive buffer goes full for some reason, you just zero the character counter without somehow setting any flag or in any other way inform your program that this have happened. Why not? Don't like debug help like that?

    4) You have a "default" in your switch statement that doesn't do anything - but the code after the switch statement is written based on the assumption that you always have received a character. Remember that your init code did turn on IER_THRE which mean the processor wants to create an interrupt to full the UART with outgoing data too - something your interrupt handler doesn't support.

    5) You have code like:

    U3IER = IER_RBR | IER_RLS;      // Re-enable receive interrupt
    

    So are there other code sections somewhere that disables the receive interrupt?

    6) You have a main loop containing:

    for(i=0;i<47;i++)
    


    But where have you maked sure that the received message really has that size? Do you just assume it, just because you assume that is the size the sending side would send? Anyone ever told you assumptions are bad, and tends to hurt?

    7) I don't see that you have any code in your ISR that tries to count how many characters you manage to pick up in a single interrupt - which would have been interesting information given that the receive FIFO have a limited size and debuging of your code should show that you are always way faster reading out data than what data comes in.

    8) You have local variables inside your ISR that is declared volatile - why? You understand the meaning of the volatile keyword? So then tell me why you think you need it for your local variables.

    9) How can you be sure that the UART doesn't receive the first characters of the next message before your main loop have had time to print the full set of characters from the previous message? Your ISR doesn't look at the flag.EOL_PC flag to verify if the buffer is free to be filled with new data.

    There are probably other issues hidden there too, but above should be enough for you to start actually doing a bit of debugging.

Children
No data