• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 32 subscribers
  • Views 5265 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C123GH6PM: default clock

Ruslan -
Prodigy 225 points
Part Number: TM4C123GH6PM

Hello Community

I started a simple blink project and it is working nicely.

I made some code myself as I am trying out the architecture and did not edit or added anything about clock frequency. I was expecting to have the default frequency of 16Mhz as stated in the documentation and some videos from TI.

In ATMEL (ATMEGA) the F_CPU if not set will automatically run the MC at 8MHZ, which is the default internal oscillator. So I was expected that here we have something similar.

Yet my board runs at 1,6MHz. any suggestions? Is it a default 1,6Mhz when nothing is set up? Is there no way avoiding setting up the SysTime?

I am using a very simple delay loop.
Yes I know I should not do it, I should set up a timer and use the SysTime or interrupts. Yes I know I should use the API and not play with registers myself.

Thank you for your answer.

  • 0
    Guru 13040 points
    Ruslan,
    Why do you say your board is running at 1.6MHz? How are you measuring such?
    Bruno
  • 0 in reply to Bruno Saraiva
    Prodigy 225 points
    Hey Bruno,

    I have a loop acting as a delay function and I flip a pin. Then I use an LED and an oscilloscope.
    My delay function is assuming 16Mhz that gives me a period of 62,5 ns. Which mean that if I want to have a cycle of 300ms I need 4800000 periods. But I get my 300ms with only 480000 periods, which is a factor of 10 lower than expected.
    I know that the numbers are not 100% correct because I am not taking under-consideration sw execution time and read/write instructions. But I am not interested in those small delays they come later.
  • 0 in reply to Ruslan -
    Guru 13040 points

    Do you mean the Tivaware's SysCtlDelay()?

    If so, the first important point is that ONE SysCtlDelay() takes 3 system cycles. Hence, to delay 300ms @16MHz, the call should be
    SysCtlDelay(1600000).

    Let us know. Are there other things happening at the same time on your system? Any interrupts enabled?

  • 0 in reply to Bruno Saraiva
    Prodigy 225 points
    a) I only have a blink function that I made myself, no interrupts or anything else set up
    b) I am not using Tivaware or the SysCtlDelay funtion.

    I have made a simple interfacing to port F and then toggle an LED. My delay is just a while loop.
  • 0 in reply to Ruslan -
    Guru 13040 points
    Ruslan,

    "just a while loop" means nothing to me.

    while(what)?

    How do you know that (what) takes one system clock?
  • 0 in reply to Bruno Saraiva
    Prodigy 225 points
    Okay I have a main function which runs the toggle and after toggle a "delay" function is called.
    The delay function runs a while loop until it reaches 0 form a number at which point it exits the loop. It returns to main and toggle pin again.
    So my question is why is the LED been toggled at 1,6Mhz or why does it take 3 system cycles to execute this function?
    Since I have not defined system clock I expected it to be faster.

    I am assuming that the while loop takes 1 system clock because there is nothing else to it. That that is my question. I do not understand why it does not take 1 system clock.
  • 0 in reply to Ruslan -
    Guru 13040 points
    From your description (which would be better serviced as a pasting of your loop here), I assume your while loop decreases a variable used as counter.

    Can you appreciate the fact that such simple arrangement needs to repeatedly:

    - decrease the counter
    - compare the new value to a fixed reference
    - move the program execution to the address where the loop starts

    All these things can't be done in one system clock, agree?

    Look at the assembly code created on your "simple while loop" - your IDE has a little window for that. There will be a few instructions there. Then, for curiosity, you can seek ARM documentation, and check how many system clocks each of those machine instructions require. From your comments above, it does appear that the whole loop takes 10 clock cycles, which is quite reasonable.
  • 0 in reply to Bruno Saraiva
    Prodigy 225 points

    I do not like posting code, sorry.

    You are correct. When I debug I see the R15 executing two commands, read and compare and the R0 been changed to the counter value, which will be a write cycle.

    Which all makes total sense, and I do not get why I got so confused.

  • 0 in reply to Ruslan -
    Guru 13040 points

    Glad you got your issue solved!

    Ruslan - said:
    I do not like posting code, sorry.

    That's fine - but such probably make it more difficult for getting help... Trust me, a while loop ain't that much of a rocket science that couldn't be publicly disclosed here...

    May we summarize to this post, as:

    - The default clock is indeed 16MHz

    - You stated that you don't use TivaWare - you should! If you plan to work with TM4C devices, you REALLY SHOULD!

    Cheers

    Bruno

  • 0 in reply to Bruno Saraiva
    Prodigy 225 points

    I do not use tivaware for a good reason.
    If you read my original post you will see that I mention it. I know I should use it, I do not :-)
    btw my while loops takes 687us i found some very exiting tools in Keil. I will set up a logic analyzer as well

  • 0 in reply to Ruslan -
    Guru 117850 points

    Ruslan - said:
    I do not use tivaware for a good reason.

    While that is "claimed" - it is notable that, "Nowhere is such "good reason" justified and/or supported.

    I would bet you that your (singular) reasons "against" cannot compete against "so many" reasons "for!"      (use of the long, tried, true, tested API)

    "Culling yourself from the "forum herd" (via rejection of the API) is almost guaranteed to, "Delay your development, add great frustration, and offer few "insights" downstream!"        After your "good reason" has passed -  the reality of "Inadequate documentation, tech support, and timely delivery" - all the result of (alleged) "good reason" - will prove of (little) aid/comfort for (any) "new efforts!"

  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:
    Ruslan -
    I do not use tivaware for a good reason.

    While that is "claimed" - it is notable that, "Nowhere is such "good reason" justified and/or supported.

    I would bet you that your (singular) reasons "against" cannot compete against "so many" reasons "for!"      (use of the long, tried, true, tested API)

    *Like*!

  • 0 in reply to Bruno Saraiva
    Guru 27665 points

    Bruno Saraiva said:
    From your description (which would be better serviced as a pasting of your loop here), I assume your while loop decreases a variable used as counter.

    Can you appreciate the fact that such simple arrangement needs to repeatedly:

    - decrease the counter
    - compare the new value to a fixed reference
    - move the program execution to the address where the loop starts

    Or depending on the exact code, it could be eliminated entirely by a good compiler.

    Robert

  • 0 in reply to Bruno Saraiva
    Guru 27665 points

    Bruno Saraiva said:
    Ruslan -
    I do not like posting code, sorry.

    That's fine - but such probably make it more difficult for getting help... Trust me, a while loop ain't that much of a rocket science that couldn't be publicly disclosed here...

    Indeed Ruslan, if you think your while loop is too proprietary then you are in the wrong line of work.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117850 points

    Robert Adsett said:
    if you think your while loop is too proprietary then you are in the wrong line of work.

    Or - such is "justified" by (another) "good reason!"      (or not)