• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 382 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.

MSP-EXP432E401Y: Getting data from UART0 with assembly code

Brad McMillan
Intellectual 620 points
Part Number: MSP-EXP432E401Y

Hi:

I have an lwip project that I'm trying to re-purpose for another application that will primarily be written in assembly code. Right now I'm trying to send and receive data through UART0.  So far I can send bytes of data by putting them in the UARTDR register at 0x4000C000 but I'm not seeing how to pick up bytes of data that have been received.

If I disable the receive FIFO I can see my data coming in at UARTDR but I can't see that there is any bit that I can read that tells me that a new byte has been received.  If I enable receive FIFO I can see that the data came in momentarily because it flashes at UARTDR, but I have no idea where the receive FIFO is located and I also don't know where the pointers to the FIFO stack are located.

I was thinking that the receive data might be getting picked up by an interrupt routine but I don't see any of the interrupt mask bits set in USARTIM.

Can anyone tell me how to talk to UART0 with assembly code?

Thank you.

  • 0
    TI__Mastermind 29376 points

    Hi Brad,

    I am sorry that I don't find more assembly reference code for UART0.

    Thanks!

    Best Regards

    Johnson

  • 0 in reply to Johnson He
    Intellectual 620 points

    Hello Johnson,

    It's been a week and still no answer.  Please escalate this up to someone who can provide an answer.  There must be someone at TI who can answer this since the part was designed by TI.

    I'm very eager to get back to developing my application and need to get this answered before I can make any progress.

    Thank you,

    Brad McMillan

  • 0
    Guru 99105 points

    According to TRM (SLAU723A) Table 26-6, the RXFE bit in the UARTFR goes low (0) if the FIFO is disabled (FEN=0) and UARTDR has data in it.

    According to TRM Sec 26.5.1, UARTDR is (also) "the interface to the FIFOs".

    i (also) haven't run across any assembly examples for the MSP432E. In addition to the TRM, I get some value from reading the source code for the DriverLib, though you'd have to translate them into assembly yourself. On my system, the DriverLib source is in:

    C:\ti\simplelink_msp432e4_sdk_3_20_00_10\source\ti\devices\msp432e4\driverlib

    [Edit: Minor clarification.]

  • 0 in reply to Bruce McKenney
    Intellectual 620 points

    I'm still having the same problem.

    First, I clear FEN (bit 4) to disable FIFO:

    0x4000C02C UART0_UART_LCRH
    0x4000C02C 60 00 00 00

    It also looks to me like the interrupts are all disabled:

    0x4000C038 UART0_UART_IM
    0x4000C038 00 00 00 00

    Here are UARTDR and UARTFR before a character is sent

    0x4000C000 UART0_UART_DR
    0x4000C000 00 00 00 00
    0x4000C018 UART0_UART_FR
    0x4000C018 97 01 00 00 00 00 00 00

    Then I send a b (62 hex):

    0x4000C000 UART0_UART_DR
    0x4000C000 62 00 00 00
    0x4000C018 UART0_UART_FR
    0x4000C018 97 01 00 00 00 00 00 00

    As you can see, the character shows up in UARTDR but RXFE (UARTFR, bit 4) does not change.

    WRT reading the source code I was able to find uart.c in simplelink_msp432e4_sdk_4_20_00_12, but I don't think that is the version that is being used in my lwip based project. My impression is that I would need to find uart.c in my project and place some breakpoints in it in order to look at the disassembled code. Is that right?

    Thank you.

  • +1 in reply to Brad McMillan
    Guru 99105 points

    That display doesn't look familiar. Is that from CCS, or your program? The reason I ask is that as soon as your program reads the (single) byte from DR, RXFE will go back to 1. Try reading FR first.

    I see a file "uartstdio.c" which provides some (slightly) higher-level functions, but it still calls into DriverLib for the low-level stuff.

  • 0 in reply to Bruce McKenney
    Intellectual 620 points

    Problem solved. The display is from the Memory Browser of the CCS Debugger pointed to address 0x4000C000. When the debugger read USATDR at address 0x4000C000 it reset RXFE back to 1 so when it got to USATFR the value had already been reset back to 0x97.

    When I changed the memory browser to 0x4000C018 and sent a character USATFR changed to 0xC7 (RXFE=0) because USATDR was never read by the debugger.

    Thank you so much for your help. I've been trying to figure this out for a couple of weeks now.