• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 924 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.

CCS/F28M35H52C: UARTStdio doesn't appear to work in UART_BUFFERED mode

Calvin Taylor25
Prodigy 170 points

Part Number: F28M35H52C
Other Parts Discussed in Thread: CONTROLSUITE

Tool/software: Code Composer Studio

Hi TI,

I'm almost certain I'm doing something stupid, but I'm stumped.

I have some software that uses the uartstdio library for terminal IO. Because I need to have the UART be non-blocking, and that requires that I be in UART_BUFFERED mode (because functions like UARTRxBytesAvail() don't even exist unless UART_BUFFERED is defined), I went ahead and set the define to 1. When I do this, the code crashes with an unexpected interrupt.

To be clear,

// #define UART_BUFFERED 1

...works fine

#define UART_BUFFERED 1

...sends me off to IntDefaultHandler().

What I'm doing really isn't all that complex. In fact, at this point, I'm not even trying to send characters in. I'm just using the library as a printf. It gets halfway through the first message and crashes (I can see "LED task initializ" on PuTTy) off to IntDefaultHandler.

My guess is that there's something else that has to be set up to use the buffered mode. An ISR, perhaps? But I'm at a loss as to what it is.

Help?

  • 0
    TI__Mastermind 42195 points
    Calvin,
    Try to find out what is causing this, set break points in your code and see what gets executed and what does not. If you think it is caused by an interrupt then you could try disabling global interrupts and see if the behavior changes. If it is caused by a interrupt that has not been correctly mapped you could look at the Peripheral Interrupt Expansion and see what is causing the interrupt to trigger.

    There are some UART examples in controlSUITE if you which may help you get started.

    Try a few of the basic debug steps I've mentioned above and we can go from there.

    Regards,
    Cody
  • 0 in reply to Cody Watkins
    Prodigy 170 points
    Hi Cody,

    I've been doing that....well, most of that. How do I look at the Peripheral Interrupt Expansion?

    What I did discover is that there's a function called UARTStdioIntHandler in uartstdio.c that isn't called by anything inside uartstdio.c nor is it listed in the uartstdio.h file for external use. I'm guessing you guys didn't finish validating the uartstdio in UART_BUFFERED mode.

    Do you happen to have any examples of the uartstdio library using UART_BUFFERED mode? I wasn't able to find any.

    Thanks for the help,

    Calvin
  • 0 in reply to Calvin Taylor25
    Prodigy 170 points
    Victory! Well, partial victory--I added UARTStdioIntHandler to uartstdio.h and invoked it after UARTStdioInit(0). It should probably be _in_ UARTStdioInit, but whatever.

    That took care of the transmit side. And it's not hanging any more. I'm still not seeing data coming back on the receive side. Here's my code:

    if(UARTRxBytesAvail()){
    uint8_t char_in=UARTgetc();
    UARTprintf("Char in %c\n", char_in);
    }

    Nothing fancy. I mean, really really not fancy.

    I thought I saw that the RX interrupt is enabled...so something else is probably going on. I'm looking into it now.

    As I mentioned in my previous post, if you do have an example of this mode actually being used, it might be helpful...at least it would suggest that someone fixed some of the bugs. :p

    Onwards!

    Calvin
  • 0 in reply to Calvin Taylor25
    TI__Mastermind 42195 points

    Calvin,

    I expect there was a good reason why it was kept out of the STDIO init function. Additionally I do not have a good example of how to used the "buffered" mode.

    What happens if you call a function like UARDRxBytesAvail()? This should tell you if bytes are stored in the buffer.

    • Are you sure you have the GPIO mux configured correctly?
    • Have connected your incoming UART signal to the correct pin/GPIO?

    Regards,
    Cody 

  • 0 in reply to Cody Watkins
    Prodigy 170 points

    I figured out the problem. The Docking Station and the ControlCard both use UART0 pins PE4 and PE5. Both run the signals into FTDI chips and off to USB ports. These show up in my device manager as serial ports. However, while both serial ports have the TX line connected, connecting both RX lines could cause contention. Therefore the RX-Slave signal is jumpered on the Docking Station. That's why I was able to see the transmit side, but not the receive. When I opened up a terminal to the other serial port, I could send traffic into the system.

    To sum--uartstdio.h has a bug: it needs to have: 

         extern void UARTStdioIntHandler();

    ...added. That should get fixed. Second, you guys should have a uartstdio example which shows how to set the UART up using the library (if you'd like me to send you some code for this, I'd be happy to). The last piece (the RX thing) could also get mentioned in the example...or maybe it's obvious to everyone but me. :p

    Anywise, I'm good to go!

    Thanks,

    Calvin