• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 380 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP432E401Y: Where is UART3 receive FIFO located

Brad McMillan
Intellectual 620 points
Part Number: MSP432E401Y


I'm trying to implement a simple RS-232 link in assembly code utilizing the information in section 26 of SLAU723A.

So far, everything is working fine except for one thing; I can't see anywhere in this document that says where the receive FIFO is located so I don't know where I should pick up any received bytes of data.

Can anyone tell me where in memory the receive FIFO is located or how I can figure out where it is located?

Thank you

  • 0
    TI__Guru**** 191906 points

    Hi,

    Brad McMillan said:
    where I should pick up any received bytes of data.

    The received data is pushed onto the RxFIFO. There is NOT a unique address for each RxFIFO location but rather you read the RxFIFO from UARTDR register. Since the RxFIFO is a FIFO (First In First Out), each time you read from UARTDR register, the FIFO pushes out the first-in (the oldest) data to the processor. Likewise, if you read again from UARTDR register, it pushes out the 2nd-in (the second oldest in the FIFO) data to the processor. 

  • 0 in reply to Charles Tsai
    Intellectual 620 points

    Hi,

    Thank you for your response. I am able to read the incoming bytes of data at UARTDR but only intermittently.  I'm using the commands from the uart_echo sample to setup UART3 and I'm wondering if they setup an interrupt routine that I'm competing with to pick up the incoming bytes.

    I thought I read that the receive interrupt was disabled if I set the FIFO depth to 1 byte which I did by setting bits 3, 4, & 5 of UARTIFLS to zeros, but I can't find where I read that now.  Can you tell me how I can disable the receive interrupt so I can make sure I'm not competing with an interrupt routine?

    Thank you again.

  • 0 in reply to Brad McMillan
    Guru 100785 points

    If you still have something that looks like [from the uart_echo example]:

    >MAP_IntEnable(INT_UART0);
    >MAP_UARTIntEnable(UART0_BASE, UART_INT_RX | UART_INT_RT);

    then that's what is enabling the Rx interrupt. Supposing that you don't need the function provided by that ISR, you can remove these lines.

    Setting UARTIFLS=0 just sets the trigger level; it doesn't disable the interrupt.

  • 0 in reply to Bruce McKenney
    Intellectual 620 points

    For clarification, my application is using UART0 to communicate over a USB port which is not having a problem. I'm using UART2 and UART3 to implement 2 RS-232 ports and the one I'm testing right now and the one I'm having this problem with is UART3.

    I found 4 commands in the main program that include IntEnable:

    UARTIntEnable(UART0_BASE, UART_INT_TX);
    SysTickIntEnable();
    UARTIntEnable(UART0_BASE, (UART_INT_OE | UART_INT_BE | UART_INT_PE | UART_INT_FE | UART_INT_RT | UART_INT_TX | UART_INT_RX));
    IntEnable(INT_UART0);

    It looks to me like these are mostly associated with UART0.  Do you think they might also be enabling the Rx interrupt over UART3?

    Is there a way I can see if the Rx interrupt over UART3 is enabled,  And, if so, is there a way I can disable it?

    Thank you so much for your help.

  • 0 in reply to Brad McMillan
    Guru 100785 points

    Enabling the UART0 interrupt won't affect UART3. (I thought maybe you had just changed all the "UART0"s to "UART3" or something.)

    In the debugger, you can look at the UART3 registers with "Window->Show View->Registers". You're looking for the IM (Interrupt Mask) register. Alternatively, search your Project for "UART3_BASE" -- there probably aren't many of them.

    How are you reading the data? Are you using not(FIFO-empty) [UARTFR:RXFE] or the Raw Interrupt Status [RIS:RXRIS]? Generally I recommend the former.

  • 0 in reply to Bruce McKenney
    Intellectual 620 points

    Under UART3 in "Window->Show View->Registers", UART_IM was all zeros.

    The only command that had UART3_BASE in it was:

    MAP_UARTConfigSetExpClk(UART3_BASE, g_ui32SysClock, 38400, 
                                                          (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));

    I'm using to following assembly language infinite loop to read the data:

    while(1)
    {
          asm("         movw r1, #0xf000 ");
          asm("         movt r1,  #0x4000 ");
          asm("         ldr r2, [r1, #0x03c] ");  // UART3_UART_RTS
          asm("         and r2, #0x10        ");  // RXRIS
          asm("         cmp r2, #0x10       ");
          asm("         bne    noin             ");
          asm("         ldr r3, [r1]              ");
          asm("         mov r3, r3             ");
          asm("noin: mov r3, r3             ");
    }

    I also tried RXFE at 0x18 and it still would not pick up the data reliably. One strange thing I've noticed is that the character I'm sending to it shows up in UART3_UART_DR after the 16th try. That tells me that there is a FIFO issue, but I set bits 3, 4, and 5 to zero in UARTIFLS which I thought meant that I would get each character as it was received and that I wouldn't need to wait until the FIFO was filling up.

    Can you see anything I'm doing wrong here?

    Thank you.

  • 0 in reply to Brad McMillan
    Guru 100785 points

    What does (un)reliably mean exactly?

    1) The indicator (RXFE) says there's a byte but it isn't the one you expect?

    2) The indicator says there isn't a byte, but the byte you expect is (visible) in DR?

    3) The indicator says there isn't a byte, the byte you expect is not in the DR, but it really should have arrived?

    Also: Are the FIFOs actually enabled [UARTLCRH:FEN]?

  • +1 in reply to Bruce McKenney
    Guru 100785 points

    I glued something together from your code fragments and I was reminded that UARTEnable sets FEN=1. 

    If you follow that call with a call to UARTFIFODisable(UART3_BASE) you'll get the byte-by-byte behavior that (I think) you want.

  • +1 in reply to Bruce McKenney
    Intellectual 620 points

    A. Here is the answer to your first post (before I read the second post)

    Here is what is happening when I use the following code that looks at RXFE

    while(1)
    {
          asm("         movw r1, #0xf000 ");
          asm("         movt r1,  #0x4000 ");
          asm("         ldr r2, [r1, #0x018] ");  // UART3_UART_FR
          asm("         and r2, #0x10        ");  // RXFE
          asm("         cmp r2, #0x00       ");
          asm("         bne    noin             ");
          asm("         ldr r3, [r1]              ");
          asm("         mov r3, r3             ");  // Breakpoint added here in Step 2.& Step 4.
          asm("noin: mov r3, r3             ");
    }

    Step 1: If I send the same character 16 times that byte will show up in UART3_UART_DR on the 16th pass and it will never show up in R3 as expected.

    Step 2: If I put a Breakpoint as shown the byte will show up in R3, but some random other byte will show up in UART3_UART_DR.

    I looked at UART_LCRH and its value was 70 so FIFO was enabled. Then I thought I actually don't want FIFO enabled so I changed the value to 60 and things got a little better:

    Step 3: Now when I send a char it shows up immediately in UART3_UART_DR every time, but it still doesn't show up in R3.

    Step 4: When I put the Breakpoint as shown, the byte shows up UART3_UART_DR and R3, but, of course I can't have a breakpoint there all the time.

    **********************************************************************************************************************

    B. Here is the answer to your second post which I didn't read before I answered the first one.

    I removed the code I had written to disable FIFO and replaced it with UARTFIFODisable(UART3_BASE).  It worked exactly like Steps 3 and 4.  I also tried using RXRIS and it also worked exactly like Steps 3 and 4.

    I think we are getting very close to solving this.  Thank you so much for helping me. 

  • 0 in reply to Brad McMillan
    Intellectual 620 points

    Actually, I think it's working.  I started thinking that it might be that my register display might not be refreshing, so I sent it a character and then I put a breakpoint in the code and the register display showed the correct value in R3.  It must be that the register display doesn't refresh when the code is in a tight infinite loop like that.

    Again, thank you so much.  You solved my problem for me. I'll press "This resolved my issue".