• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 32 subscribers
  • Views 1058 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.

Cannot configure GPIO pin for UART3 in the uart_echo board example

Peter John
Expert 1480 points

Other Parts Discussed in Thread: TM4C1294NCPDT

OK, been stuck on this for 2 days and need some help.  I have read all about the NMI unlock pins and this isn't such a case.

I'm using the DK-TM4C129X Connected Development Kit with CCS v5.4 and TivaWare v2.1.  I am also using my own custom board with a TM4C1294NCPDT.

I can run the supplied board example uart_echo fine (yay !) on both boards and it works fine and echos characters I type to the virtual COM port (via UART0 on the MCU)

I now want to change the output from UART0 to UART3.   The very first line I change fails.

I change 

GPIOPinConfigure(GPIO_PA0_U0RX);

to

GPIOPinConfigure(GPIO_PJ0_U3RX);

when I do this the execution hangs in the FaultISR(void) function in startup_ccs.c

So I read spma043.pdf and it lists my error exactly  "...the NVIC Fault Status (NVIC_FAULT_STAT) register has a value 0f 0x0000.8200.  The value shown here indicates a bus fault, and the bits that are set are BFARVALID and PRECISERR. This means that the Bus Fault Address Register (FAULTADDR) register contains the exact value of the address that triggered the bus fault."

But this doesn't help me as I already know that the fault happens at the last line of the GPIOPinConfigure function in gpio.c  (a HWREG assignment).

I forgot to mention, I need to comment out the call to PinoutSet() to make this work with my custom board as well as the DK board and I only copy and paste the required functions I need from that call then modify them as required for UART3 (shown unmodified below for UART0).

ROM_GPIOPinConfigure(GPIO_PA0_U0RX);
ROM_GPIOPinConfigure(GPIO_PA1_U0TX);
ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);

What is my problem ?

  • 0
    Guru 86865 points

    Hi Peter,

         My best guess is that you did not enable clock for UART 3 and GPIO J using these lines below.

    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART3);
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOJ);

    - kel

  • 0 in reply to Markel Robregado
    Expert 1480 points

    Markel Robregado said:
     My best guess is that you did not enable clock for UART 3 and GPIO J using these lines below.

    Thanks Kel, I can try it out in about 14 hours.   If what you write is correct, why doesn't UART0 explicitly require the clock enabled for it ?

  • 0 in reply to Peter John
    Guru 20670 points

    i did noticed this.

    Some peripherals i forget to use SysCtlPeripheralEnable but i stil works just as fine. Maybe some peripherals don't get disabled on reset?

    If so, then do i need to disable all peripherals on startup if i want to save power and only then enable the ones i need?

  • 0 in reply to Luis Afonso
    Guru 47900 points

    Luis Afonso said:
    do i need to disable all peripherals on startup if i want to save power and only then enable the ones i need?

    That's a logical procedure - but may not be required.  Where then - can the reset condition of "your registers" - be identified?  Within the MCU manual all (surely most) user-access registers reveal their, "power-up/reset" state.  Along with the clear listing of reset conditions - other "facts of interest" usually reveal...

  • 0 in reply to Peter John
    Guru 47900 points

    Peter John said:
    Why doesn't UART0 explicitly require the clock enabled for it ?

    That's unfortunate - and a most pertinent question at the same time!

    Might it be that the Eval board designers went for "ease of use" - and chose, "Port/Pins" which default into their intended usage?  That's all well and good - until you/others (most all others) attempt to, "Copy/paste" that same UART0 code to another UART - not so blessed!  (i.e. defaults into UART mode - thus reduces the number of function calls!)

    Imho - long posted here (& - as always - duly noted) UART0 should be initialized EXACTLY as any other UART!  "Saving" the few MCU function calls - as was done w/in the Eval SW examples - condemns (most) all users to (needless) pain/suffering when they copy/paste that (incomplete) UART0 initialization code into all non-UART0 applications...

    And a further caution - beware similar, "reduced SW set-up/config calls" for other peripherals (usually @ Port_A) which exhibit similar "default" behavior.  It's natural to "attach" that exact code to peripheral n+x etc. but keep in mind the default behavior is unlikely to extend to the n+x peripheral instantiations - thus a fuller set-up/config is often required...

  • 0 in reply to Peter John
    Guru 86865 points

    Peter John said:
    If what you write is correct, why doesn't UART0 explicitly require the clock enabled for it ?

    Based from datasheet under "Boot Configuration", UART0 is enabled after Power-On-Reset and Device Initialization.

    - kel

  • 0 in reply to Markel Robregado
    Expert 1480 points

    Kel, Luis and cb1, thank you all VERY much for your input to this.  Kel hit the nail on the head and identified the problem exactly. 

    The original uart_echo example DID explicitly enable UART0 and GPIO port A but I didn't initially see that.  Within PinoutSet(); all GPIO ports are enabled, but as I commented that out I mistakenly forgot to copy out the important step of enabling GPIO port J.  Now I have done so it doesn't halt execution with a FaultISR.

    Now I am going to use some type defines to allow me to easily switch between UART0 | UART 3 and PortA | PortJ.

    This excellent example code to configure any of the UARTs is a great template.