• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 1321 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:

System Clock in TM4c123GH6PM

TM4C123GH6PM: System Clock in TM4c123GH6PM

Amey M
Prodigy 60 points
Part Number: TM4C123GH6PM

Hi,

I am trying to setup UART1 have done the setting for GPIO and UART both. The data which I transmit over UART is coming to UART_DR (I am using Keil and CMSIS core Library to code it and in simulation window I can read the data in UART_DR) but I am not getting anything on UART1 window or serial console in Keil debugger.

Here are my code snippets for configuring GPIO and UART along with main function.

///////////////////////////////////////////////////////////////////////////////////////////////////////////////

#define U1RX (1<<4)
#define U1TX (1<<5)
#define PORTC (1<<2)

#define TXFF (1<<5)
#define RXFE (1<<4)
#define UART1EN (1<<0)

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

void GPIOC_Init()
{
SYSCTL->RCGCGPIO |= PORTC ; //Enable PORTC
GPIOC->AFSEL |= (U1TX | U1RX); // Set Pin Functions to Alternate Functions
GPIOC->PCTL = (GPIOC->PCTL & 0xFF00FFFF) + 0x00220000; //Set Alternate Functions to UART1 (PMC5 = 0x0010 and PMC4 = 0x0010)
GPIOC->DEN |= (U1TX | U1RX); //Enable Digital functionality to UART Pins (PC4 = 1 and PC5 = 1)
GPIOC->AMSEL &= ~(U1TX |U1RX);

}

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

void UART_Init()
{
SYSCTL->RCGCUART = 0x02; // Enable UART1
UART1->CTL |=~UART1EN ; //Disable UART before configuration

UART1->IBRD = 0x08;
UART1->FBRD = 0x2C; // Baud Clock is 16MHz and BR = 115200
UART1->LCRH = 0x60; // 8N1, FEN disabled
UART1->CC = 0x5; // Select clock source as PIOSC System Clock
UART1->CTL |= UART1EN; // Enable UART

}

////////////////////////////////////////////////////////////////////////////////////////////////////////////

int main()
{
uint8_t data[] = {"TM4C123GH6PM UART TX DEMO"};
uint8_t i, ch;

GPIOC_Init();
UART_Init();

for (i = 0; data[i] != '\0'; i++)
UART_Send(data[i]);

while(1);
}

I also have disabled clock setup in system_TM4C123.c file which is being used at startup. So after doing all this I am not understanding why m I not getting data on console while I get it in UART_DR?

  • 0
    Guru 117855 points

    My friend - even as an occasional Keil IDE user - your issue is, "SO Keil-centric" (especially the Keil Serial Console part) that I'm, "At a loss."

    Due to such STRONG Keil emphasis - would not your question benefit by "inclusion" upon their forum - as well?

    And - was it not (past) noted - that your (continued) use of "DRM" adds significant, "Time/Effort" to your "Helper Crüe!"    You DO care for us (at least somewhat) - is that not true?    Employing the vastly more popular - and efficient - vendor API - would  "Speed & Simplify" your Helpers' efforts - and more importantly - your own!

    We note too - your Subject Line, "System Clock in TM4C..." seems (almost) incidental - when weighed against the bulk of your  overwhelmingly, "Keil-centric" post...

  • 0 in reply to cb1_mobile
    Prodigy 60 points
    Thank you cb1_mobile for your kind attention towards my problem.

    I agree to you that I mentioned my issue with Keil console but actually I thought I am doing something wrong in configuring Clock or Peripheral and as the device I am using is from TI I thought I can put it up on the E2E community. My aim was to figure out the mistake I am making w.r.t device configuration.

    Also, regarding adding this question here is same reason that I thought I am messing with clock configuration and I supposed this thread belongs to System Clock in TM4C I thought it could be right place. I am really sorry for adding question here as I did not think of implications at the time of posting it. I agree with you that posting this question here is misleading as my question does not clear my intent of finding my mistake with clock configuration.

    Thank you for bringing this to my notice, I will create new thread by clicking as a new question tab. :)

    Now regarding vendor APIs, Yes I agree that using APIs would speed the process but as I am a hardware engineer and trying to code after long time I thought I should code kind of bare metal for at least standard peripherals such as UART, I2C, SPI etc so that I can brush up my embedded skills to very basic levels and once I am comfortable doing so then I can use standard APIs.Please let me know if this approach is correct or wrong? I am sorry if it has caused trouble. I did not intent that.

    Once again thank you so much for making me realize that while posting question I should be little alert and post my questions as clear as possible so that it will be easy for people to help me and resolve my problem. I will definitely take care in future and for now I will create new thread for this question.

    Thank you,
    Amey
  • 0
    Genius 3850 points
    this may help: github.com/.../TM4C_LM4F120

    it is written on top of the TM4C CMSIS header files so it should be a copy and paste for your chip.

    You can also see LM3S files - similarly written. big fan of those struct-based approaches and hope TI will adopt them one day.

    the crazy thing is that those header files are created by TI so there is no reason they don't distribute them via CCS too.
  • 0 in reply to Amey M
    Genius 3850 points

    "Please let me know if this approach is correct or wrong?"

    this is no "correct" or "wrong" approach for all cases. whatever works best for you.

    For those TI chips, I started with Stellarisware back in the day, but used them through a middle layer, with the goal then to get rid of Stellarisware / Tivware. The OEM libraries allow you to get up on a new chip quickly but they aren't written for your coding style or applications so they are not the most efficient nor the easiest to use.

    the use of a middle layer allows me to port my code to a different chip without much modifications to my code base: linking in the right middle layer for the target and I'm in business.

    The "register" approach that Luminary took and TI takes makes coding a complex chip more difficult so I opted for the CMSIS header files. No regret whatsoever. I think as the whole industry has pretty much moved in that direction, it is only a matter of time for TI to do so as well.

  • 0 in reply to Danny F
    Genius 3850 points
    "UART1->CTL |=~UART1EN ; //Disable UART before configuration"

    that line is wrong.

    I also didn't see Uart_send() but in general you should poll the flag to make sure that the buffer or the shift register is empty before loading it with new data.

    See my code examples posted earlier.
  • 0 in reply to Amey M
    Guru 117855 points

    My friend - no one believes - or seeks - any apology.     My intent was to notify - as your post was (hugely) "Insider" Keil based (again - especially the "Serial Console part!")     That's a "bit much" for (most) forum users - here.

    Amey M said:
    thought I should code kind of bare metal for at least standard peripherals such as UART, I2C, SPI etc so that I can brush up my embedded skills to very basic levels and once I am comfortable doing so then I can use standard APIs.

    You are not alone in such (pardon) "Unjustified - Wishing/Hoping!"    You chose the word "thought" - yet there is absolutely,  "Not one word which describes, explains or justifies - just how  "DRM"  meets such, "Embedded Skills Brush-Up!"    Minus such "justification" - can the word "thought" - fully/properly be sanctioned?     This is why the words,  Wish/Hope - to my mind - prove superior "as "DRM's"  Benefit Descriptors!"   Not that there's anything (wrong) w/"Wish/Hope!"     

    To your reasonable quest for,  "Amplified Bare Metal" understanding - how is that gained - in any way - at all - by consistently,  "Failed Program Development?"    

    Does not your (highly likely) "success" - via the,  "Long Proven, Tried-True, Immensely Detailed API" - in concert w/your detailed view of key Registers (via the "open" MCU Manual)  FAR BETTER - "Boost your bare metal competency?"    (while being  faster & easier - & far more documented!)

    You may wish to ask - "Why (always) are such claims made in behalf of "DRM" - yet (absent entirely) - of the ability of  "API Users" - to  "view & probe" - those  "EXACT SAME MCU Registers?"    

    Further  - as much "Added Learning" is claimed under DRM - why, "Do SO MANY (just like you) require "rescue" - when such  "added learning" yields  (repeated) FAILED PROGRAMS!     Might such (oft repeated)  yet never justified/described "claim" be a,  "Huge Over-statement - devoid of ANY Fact?"

    Have not  "DRM proponents" (perhaps "both" of them) not,  "Conveniently over-looked"  the obvious fact that  "MCU Register Study/Review" - is by NO MEANS - the exclusive province of (the archaic) DRM?

  • 0 in reply to Danny F
    Genius 3850 points

    here is an example that demonstrates the beauty of the struct-based approach.

    in my uart0.c/.h file, I had defined UARTx as such:

    //#define UARTx				UART0

    UART0 is defined in the CMSIS-styled header file for that device, as are UART1..7.

    from that point onward, the coding was done exclusive to UARTx, not UART0. For example:

    	//stop the uart
	UARTx->CTL &=~(1<<0);					//1->enable uart, 0->disable uart

    or 

    		//calculate the integer baud rate
		UARTx->IBRD = F_UART / baudrate / 8;
		//calculate the fractional baud rate = 64*fraction
		UARTx->FBRD = (8 * F_UART / baudrate - UART0->IBRD * 64);

    Once the work for uart0 is done, I can simply copy-and-paste the code and change the UARTx definition to UART1..7, hit recompile and I'm in business.

    that kind of approach is impossible under the register definitions in the stock header files provided by TI. 

  • 0 in reply to Danny F
    Guru 117855 points

    Danny F said:
     that kind of approach is impossible under the register definitions in the stock header files provided by TI. 

    Does the comment (above) - not ring more (or even somewhat) "True" - when  reasonably  supported & justified?     Otherwise - is it not  (undocumented) opinion?"

    Having used those very,  "Register Definitions" - and "Stock Header Files" - is it not "immediately noted" that,  "Substantial degrees of  "Coding Parallelism" exist w/in the API?"      Especially between "Multiple  instantiations" - of each MCU Peripheral.     (to include poster's,  "Multiple UART  use case.")

    Lastly - have you not (conveniently)  "glossed over" the significant, "Added Time/Effort Required" - by  "each/every MCU Peripheral"  (you may have noted - there ARE MANY) in the  attempt to create such, (only) alleged,  "Structured Panacea?"     And  have not the "vast number" of,  "Tested/Proven/Extensive Code Examples"  been  painfully degraded - via such "structured method?"

    Might the alleged "beauty" of this structured approach - exist (primarily) - thru the (overly rosy) lens - of a,  "True Believer?"

    By FAR - the API,  "best meets the  present & on-going,  "Efficiency & Robust Programming/Learning needs" of  MOST ALL here."     (even those - equipped w/"Rosy Lenses.")