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

CCS/TM4C123GH6PM: I can not set PF0 to high or low in tm4c123g development board

Lai Weiyu
Prodigy 120 points
Part Number: TM4C123GH6PM

Tool/software: Code Composer Studio

I use example "hello.c".

This is my code.

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

int
main(void)
{

ROM_FPULazyStackingEnable();

ROM_SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ |
SYSCTL_OSC_MAIN);

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);

ROM_GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_0);

ROM_GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_2);

ConfigureUART();


UARTprintf("Hello, world!\n");

GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_0, GPIO_PIN_0);  


while(1)
{
//
// Turn on the BLUE LED.
//
GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, GPIO_PIN_2);

//
// Delay for a bit.
//
SysCtlDelay(SysCtlClockGet() / 10 / 3);

//
// Turn off the BLUE LED.
//
GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, 0);

//
// Delay for a bit.
//
SysCtlDelay(SysCtlClockGet() / 10 / 3);
}
}

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

I set PF0 to high or low, I always measure 2 voltage in this pin.


Where do I need to set it?

  • 0
    Guru 117855 points

    Might that occur as you (likely) "missed" the known fact that PF_0 defaults into "NMI" status - which precludes your use for (other) purposes!

    You must employ the special, "Pin Unlocking Procedure" - which is detailed w/in MANY posts here - and accessed via "Search Box" (atop the forum.)

    Or - faster & more simply - you may AVOID troublesome "PF_0" and (partner in identical crime, PD_7) by using a "normal" GPIO, instead.     Thus no "delightful" extra effort is demanded!

    Many of your fellows have fallen victim to such an unwise & unwanted "NMI default."     No/Zero effort has been made to correct this short-coming - which always results in posts "such as yours."

  • 0
    TI__Guru 72500 points

    CB1 is correct. Here are some snippets from the datasheet describing the condition.

  • 0 in reply to Bob Crosby
    Guru 117855 points

    Bob - we (all) must note that the "effective" highlights you've deployed, "DO NOT APPEAR ANYWHERE" w/in the 1,000 page plus MCU manual.    Nor elsewhere - to the best of my knowledge!

    Thus - the (clearly) TOO WEAK (and buried) existing warnings have LONG proven INEFFECTIVE - as they are, especially easy to MISS!    

    Myself/others have LONG reported this - and (as stated) NO/ZERO corrective efforts have been launched!    

    Proof positive of this LONG KNOWN FACT - poster's arrival here - followed (surely) by many of his fellows!    Not good!    (none of this "your" doing - but concern for the correction of a KNOWN WEAKNESS seems less than apparent, here!)

  • 0 in reply to cb1_mobile
    TI__Guru 72500 points
    I acknowledge and contritely accept your chastisement. Even having that issue as the first part of the top "sticky post" titled "Diagnosing Common Development Problems and Tips & Info for TM4C Devices " has failed to highlight this issue enough.
  • 0 in reply to Bob Crosby
    Guru 117855 points

    Again Bob - never (rarely) is my commentary directed toward "individuals" (you especially - stand blameless.)      (yet courtesy your wife - not horseless.)

    Top "sticky post" - of course - is NOT where the "Road OUT Sign" is best placed - is that not true?     Few here (to include this reporter) would vector to "Diagnosing Problems" (if they even note that) when starting a fresh project.      Thus - too many here - are condemned to, "Fall from the high cliff - which is painfully UNMARKED!

    As long & repeatedly suggested - this "NMI as default" (even that questionable) requires "multiple, bold placements - sure to be noted - across multiple documents - even across that "sacred (RED) ground" (atop the forum) unwisely reserved for, "Blogs, Groups, Videos."

    None of this "rocket science" - has long been known - and "allowed" to fester - eating time/effort of too many!     That's sad commentary - is it not?

    Bob - no one here expects, "Vendor Perfection."     (admission of  "chip" in that perfection "armor" may explain vendor's inaction)     Surely (some) "Care for Users" should cause (some) attempt to, "Highlight thus Safeguard Client-Users from a LONG KNOWN, inadequately presented/conveyed warning - which has impacted SO MANY!       (well over 100 forum reports - here todate!)

  • 0 in reply to cb1_mobile
    Guru 13040 points
    cb1, Bob,

    Trying to be proactive, a few Datasheet places where a at least a footnote could be added:

    - Table 23-2 Signals by Pin Number
    - Table 23-3 Signals by Signal Name (both next to the PF0 entry AND next to anything else that can be used on same physical pin)
    - Table 10-2 GPIO Pins and Alternate Functions

    And in the DRL-UG, chapter 14.2.3.19 - GPIOPinConfigure() - could add the information that "this function does not unlock protected pins such as NMI, which must have their registers unlocked prior to a function change".

    But I can't complain too much, if you consider that the information is available at 10.1, the first sub-chapter inside GPIO! If a developer has a problem with GPIO and does not read as far as into GPIO.1 chapter, can he really expect to grow?

    Further, have we the right to complain that a reader posts such a question without ever searching for the answer first??? If 100 posters reported it, I'd say we rather limit ourselves to reply "please read this post: (link...)". I can assume that for these 100, other 9900 users actually quickly found the answer.

    Anyway... holidays ahead, may most of us take a brake! Not my case for the time being, unfortunately.

    Cheers
    Bruno
  • 0 in reply to Bruno Saraiva
    Guru 117855 points

    Bruno - mon ami,

    Bruno Saraiva said:
    Trying to be proactive

    Has not that, "Ship to Proactive" long sailed/departed?    FIVE + Years ago - as we recall.     This short-coming has - for SO LONG - been known!     While your effort in identifying (potential) points for "added warnings" is appreciated - it can in NO WAY be claimed as "Proactive."     And - that's clearly the vendor's job - our job is to bring this matter to the vendor's attention - and we've done such!

    Bruno Saraiva said:
    user has a problem with GPIO - does not read far - can he really expect to grow?

    Bruno, Is not your key (quoted) word, "expect?"      Do not 90%+ of the MCU's GPIOs perform - exactly - as the unwarned user would expect?     Indeed they do - so the user is (easily) entrapped!

    Indeed the poster "should have searched" - yet, "Search for what?"    Would it dawn to search upon PF_0?      Preventing such unexpected (and unnerving) such issue - rather than "demanding" such search - is (very ) much preferred!

    Bruno Saraiva said:
    I can assume that for these 100

    100 was FAR too conservative a number - Searching upon "PF_0" (alone) returns beyond 500 past posts!    (scroll goes "on & on" - seemingly forever.)    Note that those who DID "search successfully" - would not (properly) add to the total, "PF_0 hits."    

    Bruno Saraiva said:
    other 9900 users actually quickly found the answer.

    Your "9900" Pure Rubbish!       And - you of course - can offer NO/ZERO support for (any) claim of "quickly" finding the answer!       Unsupported "claims" ring "hollow" - reveal "desperation" - and totally fail...

    You appear to side w/"Users be damned!"     Discover, "on your own" - employing (microscopic - minimally effective) warnings/cautions!     Not (exactly) marketing textbook...

    You (surely) noted that - to (properly convey) the "well hidden NMI caution" (which you seem to defend) - our Vendor "found the need" to ADD HIGHLIGHT - so that - hapless users would enjoy (some chance) of finally noting - the (for SO LONG) well-hidden caution!

    And - left for your consideration - if, "So well known an issue is allowed to persist" (for so long) - how does this speak to multiple other issues - not so "well known?"     That's important - and likely "REPEATS" (ineffective alerts/warnings) - does it not?

  • 0 in reply to cb1_mobile
    Guru 13040 points
    cb1,
    The path from "good intentions" to "results" inside corporations is a long and rocky one. It is a nightmare when some people inside the companies are well aware of what is needed, but simply can't get the end result done - I feel the same pain inside my own realms, and that is why I tend to be a bit softer on these things. Again: method, system, continuous improvement, persistence, all come into play.
    Your criticism to my late pro-activity ain't fair - I was not here 5 years ago to have known that those very points had been raised.
    Now, you are fully correct when you curse/complain for lack of action on vendor's side - they should create some sort of quality checklist for MCU datasheets and determine a time frame so that all existing ones are revised and brought to compliance. Simple and effective as that. And we users could help by giving the opinion on the checklist content itself.
    One thing I hate? Erratas!!!! Once an issue is know to the point of an errata being ready for publishing, I'd just say each of those points should simply be inserted on an updated datasheet - and the errata should just be a table with revision entries and dates in a proper part of the doc. Most erratas have software go-arounds, but when they don't, it is quite hard to avoid being caught before your board is populated!
    Back to your wrathy reply, mon ami, you replied one question yourself - what should poster have searched, PF0??? Exact! Or at least read the sticky posts once in his life, to learn that "some pins are special" - and when in the future a pin decides to be stubborn, one will remember to come back and simply check if the chosen pin is on that list - not toooo difficult.
    Allez, mon ami! La vie es belle!
    Santée
    Bruno
  • 0 in reply to Bruno Saraiva
    Guru 117855 points
    It is my "belief" now that you DO NOT support, "User-Clients be damned!" (We'll clarify - even highlight - WHEN WE GET TO IT!) (if ever)
    On the "proactive note" - the GREAT passage of time did not "Point toward you" - but to the simple fact that "proactive" (appears) "Nowhere in evidence" as regards this long known - minimally addressed - festering issue. (it is impossible to "call proactive" after 5 years of ignoring.)

    It is noted that you "ducked" the final (critical) point w/in 28 April's 16:38 post. As "LONG KNOWN" issues (appear) near dismissed - what is to become of (the many) not (yet) so well-known? Prompt, caring, appropriate action is either TAKEN - or (enter unacceptable alternative du jour.)
  • 0 in reply to cb1_mobile
    Prodigy 120 points

    Thanks you all,I tried all yours suggestion and the problem solved now.

    Many thanks,

    WeiYu

  • 0 in reply to Lai Weiyu
    Guru 117855 points
    Thank you too - my friend - your "Verify" much appreciated. (keeps our 40W incandescent lighting beaming brightly.)

    You may wish to "permanently list" (PF0 & PD7 as requiring that special "unlock treatment.") Each of our firm's workstations includes such a warning - it is wasteful to "repeat" that error - especially as the newest MCU manuals add pages - yet continue to resist "bold and/or color highlighting" - which best serve to aid recognition.