• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 664 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.

UART reset affects other uarts on BeagleBone???

Gil Crouse
Prodigy 60 points

Hey,

I'm working on a StarterWare application using several different UARTS.  Currently I'm using the uartStdio library (on UART0) for printing out messages and debugging and I'm trying to use UART5 for another interface.  My program seems to be running fine reading UART5 and sending data out on UART5, but once I call UARTModuleReset on UART5 during initialization, I no longer get any of the messages I'm sending to the console (UART0).  Anyone have any suggestions for tracking that down?

Gil Crouse

  • 0
    TI__Prodigy 625 points

    Hello Gil,

    The behavior you are mentioning of is indeed strange. Any operation on one UART instance should not affect the other UART instances.

    • I understand from your statements that before you called UARTModuleReset() API for UART5, both UART5 and UART0 worked successfully side-by-side. What was the need to reset UART5 instance at this point of time?

    • How are you using the UART5 instance on Beaglebone board? Can you describe you hardware setup in brief?

    Please share any other information which you feel worth sharing and that which will be helpful for us to understand your setup and software better.

    Thanks and Regards.

    Gurudutt.

  • 0 in reply to Gurudutt Bharadwaj
    Prodigy 60 points

    Turns out my diagnosis was way off base.  The error is a problem accessing the SYSC registers for the UART.  If I run the following program everything is fine.

    int
    main(void)
    {

        unsigned int sysc = SOC_UART_0_REGS + UART_SYSC;
        HWREG(sysc) |= (UART_SYSC_SOFTRESET);

    }

    However, if I try to reset any of the other UARTs (e.g. change SOC_UART_0_REGS -> SOC_UART_5_REGS in the above code) I get some sort of fault and the CPU branches to the address 0x4030fc10. 

    Any ideas?  Thanks.

    Gil Crouse

  • 0 in reply to Gil Crouse
    Prodigy 60 points

    Okay, so apparently you need to wakeup the UART modules before you can talk to them.  Talking to UART0 worked because its clock had already been turned on in the boot code, but all the others were off so they needed initializing.  Example code for any other novices out there:

    /* Enable clock for UART5 */

    regVal = (HWREG(SOC_CM_PER_REGS + CM_PER_UART5_CLKCTRL) &
    ~(CM_PER_UART5_CLKCTRL_MODULEMODE));

    regVal |= CM_PER_UART5_CLKCTRL_MODULEMODE_ENABLE;

    HWREG(SOC_CM_PER_REGS + CM_PER_UART5_CLKCTRL) = regVal;

  • 0 in reply to Gil Crouse
    TI__Prodigy 625 points

    Hello Gil,

    It is glad that you resolved the issue on your own. I would like to add few more points to your discovery.

    As you have said, the functional clocks for UART0 are enabled in the Boot code. Thereafter, UART0 would be used for printing some messages on the serial console. Adding to this, we also enable the functional clocks of UART0 in the application. When you used the UART Utility Library, you would essentially have invoked the function UARTStdioInit() before using any other utility functions. This would enable the functional clocks, perform Pin Multiplexing and initialize the UART0 instance. The reason behind enabling UART0 in the application becomes clear when the application is loaded using CCS. The GEL files which does system level configuration does not enable the functional clocks of UART0, unlike the bootloader.

    Please revert for any queries.

    Thanks and Regards.

    Gurudutt.