• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 947 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.

TM4C123GH6PM: TM4C123GH6PM Datasheet: PWM definition error?

Leonardo Chiodi
Intellectual 290 points
Part Number: TM4C123GH6PM

Hi all,

I'm trying to develop a new PWM routine, and I'm follow the datasheet initialization configuration, but I found something that I don't understaand.


On the datasheet, in the chapter of the PWM, exactly on chapter 20.4 "Initialization and configuration": page 1239 at point 1, the datasheet says: "Enable the PWM clock by writing a value of 0x0010.0000 to the RCGC0 register in the System Control module (see page 456)".

But, if I go on the page 456, the RCGC0 register is a read-only register.

How can I write any kind of value in a read-only register?

  • 0
    TI__Guru**** 244400 points
    Hello Leonardo

    Well it is incorrect for sure. The method specified is also riddled with issue. It must have been the RCGCPWM register and the bit corresponding to the instance of the peripheral.

    Now coming back to the development of the routine, I hope you are not engaging in DRM code development; rather using the Tivaware.
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Amit Ashara said:
    I hope you are not engaging in DRM code development

    Appears even worse - poster (alas in mice-type) describes "ASSEMBLY" as his "Weapon of choice..."

  • 0
    Guru 13040 points
    Leonardo, can I suggest you adopt the use of Tivaware instead of frying your brains dealing with bits inside registers?
    You will probably achieve what you need with 3 or 4 lines of code, and will be backed up by a proven solution!
    Take a look on this thread to get some further info on the PWM terminology, it might be of help:
    e2e.ti.com/.../2033482
  • 0 in reply to Bruno Saraiva
    Intellectual 290 points

    First of all, thanks to all of you.

    But I firmly want to code in assembly, for me is the best suited languange for my requirements.

    The only thing that I wanted to know was is if that part of the datasheet was wrong, or not.

    It don't care for me achieve my target with 2 lines against 200, but is very important for me to deep understand how processor behave, and I think that assembly in this perspective would be better than C, or any other language.

    Thanks.

    Bye

  • 0 in reply to Leonardo Chiodi
    Guru 13040 points
    Leonardo,
    Myself, I wouldn't have time at the moment to dig into the datasheet and try to help you saying it is wrong or not.
    But I'll just once more give one suggestion: build a working piece of code based on Tivaware, and simply look the register values by debugging the code step by step.
    Once you are happy with the results, you will be able to easily create assembly code to do it all "under your control".
    And trust me, the Tivaware API's, on their very core, are not much more than simple values written to registers...
    Cheers
    Bruno
  • 0 in reply to Bruno Saraiva
    Guru 47900 points

    Bruno - poster's response, "for me is the best suited language for my requirements" is (as always) minus ANY justification as to why, "Assembly is (claimed) to be best suited!"

    Might the discovery of "Best Suited" properly involve:

    • time required to completely develop working code
    • time testing such (working) code to confirm robustness - under a wide variety of conditions
    • ability to receive support & guidance from skilled others
    • recognition of any/all "special coding sequences" which are required  (how does a neophyte user detect these?)
    • attaching one's "design-wagon" to a series of clear, focused, code examples which have been tried/true and exhaustively tested

    Perhaps the "Five BLACK Marks" (all against Assembly) throw into question poster's claim (a highly wishful one) of "best suited."

    Death blow - as you've suggested - review of the tried/true/tested vendor API - prior to the heartache/headache of (worse suited) Assembly!

    It has come as NO SURPRISE that this poster - and all those before him (w/similar, mistaken belief) provide NO/ZERO support for their "best suited" claim...