General purpose timer module (GPTM) on TM4C123GH6PM

Hello Vikram,

On TM4C123 device the System Clock is the only clock source referenced by the GPTM.

Secondly, the crystal frequency of 80Mhz is not mentioned in any of TIVA data sheets. The maximum crystal frequency supported is 25MHz. The 80MHz is the output of the PLL which can be sourced either from the external crystal or the PIOSC.

Lastly, you are right. By default if the Flash has code and the POR is applied the default system clock is PIOSC of 16MHz.

Regards

Amit

Hello Amit,

I request you to check the datasheet for TM4C123GM6PM, on Pg 707, table 11.5. "The following table shows a variety of configurations for a 16-bit free-running timer while using the prescaler. All values assume an 80-MHz clock with Tc=12.5 ns (clock period)." This is the statement I am referring to.!!

So, you mean that by default if I am not using the PLL, GPTM uses the clock frequency of 16MHz.

I request you to provide me with application notes or other material on the various clock sources and explanation for the main clock tree diagram on that datasheet I am telling you on pg220 

Hello Vikram,

I merely was mentioning that 80Mhz System Clock is different from 80MHz crystal as was mentioned in the first post. The 80MHz System Clock is only derived from a PLL.

You are right in the assessment, that the default clock is the 16MHz PIOSC and not the PLL and not only GPTM but most of the modules including Cortex M4 will be working of this clock, till the application code calls the SysCtlClockSet function for using a higher frequency clock from PLL or the Main Oscillator.

As for the Clock Tree, the data sheet is the only source. You may be able to find in the forum some explanations for clock sources, clock trees.

Regards

Amit

Hello Amit,

Hello Amit,

Actually I am trying to use the Direct Register Access Programming Model to write codes.

My impression is that I may get a better understanding of the MCU by using the Direct Register Access Model. Therefore I prefer, Directly accesssing the registers. I will try and use the APIs as you suggested.

Thanks a lot for listing the issues. While using this model i encountered the issue you highlighted that PF0 is a locked. I had successfully resolved that problem when I needed to use SW2 in one of my codes.

Warm regards,

Vikram

Hello Vikram,

The Direct Register Access Model can be tricky without understanding the nuances of programming in TM4C. The suggestion was meant to first get you comfortable with the device before running a deep dive.

Regards

Amit

I will second Amit's suggestion. 

Option 1, Use the TivaWare API: Get some working code doing something fun first.  Experience a sense of accomplishment.  Then dig into each API (they are all open source) and learn how the TI folks made the functions work in the first place.  Thus learning about the MCU in the process. 

Option 2, Forego the years of work that other have done before you and re-invent the wheel for sake of "learning": Bang head against the wall for days, frustrate yourself and folks on the forums.  Eventually get a similar understanding that you could have had in only a few hours by using the API's and examining how they work. Work being operative.  Perhaps you will have a "deeper" understanding of the MCU in the process.

In the working world I find that it is often helpful to get as much understanding as is needed to do the job and then just a little bit more as a sanity check.  If you take the time to get a full and complete understanding of all facets of the MCU, project, etc then likely you competition will have already shipped a product and won the market.

Never would I forego quality in this process, however, I believe strongly that the code written and tested and used for years buy a multitude will almost surely be of higher quality then what we re-invent ourselves to do the same job. 

One does not first learn to cook by becoming a PhD in chemistry. 

Dexter

INTEGRIS Dexter said:

learn how the TI folks made the functions work

Did not the great bulk of API MCU code here (but for 129) spring from predecessor firm? 

And - one notes most PhD chemists (in training) prefer safety/comfort of APIs as opposed to, "direct reaction" methods...

OK.  TI and Luminary Micro folks.

In fact to my knowledge/understanding up to the point the 129 was introduced and during development of the bulk of 129 APIs a large contingent of the Luminary Micro team was still on the case.

Well said dexter!!....thanks a lot guys !!! ....I am glad to hear nice suggestions here!!

Hello friends,

I am able to configure the GPTM with both APIs and Direct register model. I am toggling an LED at specific time delay generated by GPTM.However, I have observed one things in the code. If I am using the interrupts I am able to run my program properly, but, if am using while loop and the if condition , the program fails to function properly,

What I am able to infer from this problem is that GPTM runs on the system clock and since I have not configured system clock using s/w, I am using the 16MHz crystal for both GPTM and operation of the processor.

Therefore, the if statement might not be able to catch the condition properly since GPTM is working on the same clock.

Will this problem be solved if I can , by any means i can do this:

clock to processor> clock to GPTM

 Regards,

Vikram

Hello Vikram

In my first post I had already made the comment

4. The if condition while loop may or may not get hit.

You can solve by using less than operator instead of compare equal to operator which would make it inaccurate though.

Regards

Amit