• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 30 subscribers
  • Views 203 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.

Original question:

[FAQ] SW-TM4C: How to prevent the program from going into FaultISR when using a new peripheral

TM4C1294NCPDT: Requirements for Enabling Peripherals

Vince Schielack
Prodigy 30 points
Part Number: TM4C1294NCPDT

I have noticed in some example codes there seem to be some unnecessary calls to SysCtlPeripheralEnable().  For example:

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);

Is it necessary to call both?

I seem to have mixed results when commenting the first line out.  Doesn't the UART0 enable line catch everything needed for UART0 to work, or does GPIOA need to be called as well since UART0 uses those pins?

  • +1
    TI__Guru*** 135355 points

    Hello Vince,

    Both calls are required.

    The System Control (SysCtl) for the device handles the initial system-wide configuration for each individual peripheral which most importantly including routing clocking to them. The UART and GPIO peripherals are entirely separate and there is a distinct clock path that needs to enabled each UART instance and each GPIO port. Enabling the UART0 peripheral only routes the clocking to UART0 and it does not impact the GPIO at all.

    Furthermore, most UART (and other peripheral) ports are muxed with multiple GPIO so the TivaWare drivers cannot know which pins need to be enabled by the application and automate it in software - the user has to clarify which pins are used as the case where UART0 TX/RX are only on a specific I/O each is rare overall.

    Best Regards,

    Ralph Jacobi