TM4C123GH6PM: GPIOPinWrite issue

Provided your "definition" of "GPIO_GREEN_LED" does not INTRUDE into (any) of PC0-PC3 you should be ok.
This assumes that parameter two (as described) avoids (any) pins w/in PC0-PC3. (those reserved for JTAG)

Fortunately there exists a method for (often) board recovery.    Your use of the forum Search Box (atop this page) aimed at "Debug Port Unlock, or Recovery, similar" should reveal the details...

Most here use "LM Flash Programmer" - Utilities Tab - which reveals "Debug Port Unlock."     (or did - under our older version of LM Flash Programmer - which we've not used due to the proven superiority of J-Link and its (improved) differing methods...)   

Marco Bongini said:

It works, but another device I am using is connected to PORT C and PIN 5. After using the function I mentioned above, the device does not work anymore.

Friend Bruno - would not PC5 be controlled via 0x20 - not 0x40?

Hi Ralph,

His writing IS (somewhat) confusing - yet (as my quote noted) poster complains that PC5 (alone) yields, "the device does not work anymore!"    

As poster (past) succeeded w/"PC6" (surely 0x40) I believe (most) jury members would agree w/PC5s employ of 0x20...

As always - devil in the (this time) written details - and those are "unclear."

(Do vector to your "compatriot poster (of PC2 impacting PC3 fame) and see if you "buy into" my latest "remote diagnostics."   (in the attempt to save you more time/effort - so clearly this is user-client fault)

Hi cb1,

Currently Marco's wording indicates:

• LED is on PC6
• Other Device is on PC5
• LED can be turned on/off with GPIOPinWrite(GPIO_LED_BASE, GPIO_GREEN_LED, 0x00);
• Claim that problem is GPIOPinWrite(GPIO_LED_BASE, GPIO_GREEN_LED, 0x00); is causing issue with device on PC5, making it turn off as well.

Therefore the primary question is what is GPIO_GREEN_LED defined as. Definitely agree the root cause of the post request is that the device on PC5 is not working, I was just trying to clarify that Bruno's question was to validate that the GPIO_GREEN_LED value which is used on the reported problem function but not yet explained in detail as to WHAT that represents is in fact 0x40 and nothing but 0x40 so ONLY PC6 is the being changed by that line of code. This is our consensus hopeful assumption, but not yet validated!

Also we currently don't even know what the settings for this PC5 device are... much more info is needed, I think we would all agree yes?

Hopefully Marco will provide us such details soon.

cb1_mobile said:

would not PC5 be controlled via 0x20 - not 0x40?

Your sentence is correct. But poster needs to control PC6.

PC5 is what he does not want to be controlled.

Bruno Saraiva said:

PC5 is what he does not want to be controlled.

Pardon - I don't "get" that from poster's writings.    (two against one here - let's look again at the "few" facts in evidence.)

Poster writes (this a "true copy") "Another device I am using is connected to PORT C and PIN 5."     

Now - as poster has - quite deliberately - made a connection to PC5 - "HOW can you believe that PC5 is to be (either) unread or uncontrolled?"

Can I admit my "pleasure" in the fact that "neither of you" - have as of yet - demanded my (forced repair) of your "disordered controllers" - via my J-Link (while my entire 6-2, 235 lbs body - shakes in fear!)

Pardon but EVERYTHING rests upon the value of "GPIO_GREEN_LED" used in that specific command!      That remains unknown - might it have been modified elsewhere - w/in your program?

Charles Tsai said:

Can you make sure there is no shorts or anything between the two pins on your board?

Hi Charles,

Your compatriot "Ralph" and I - very early - may have felt that "short" potential too - but (closer) inspection reveals a "delay" between the 2 signals - which proves a "dc short" unlikely.

Firm/I have seen such signal "ghosting" when the input is (very) high impedance - the traces run close together - and in parallel for several inches - and the "exciting signal has a (very) fast signal edge!

Ciao Marco,

Your issue is certainly not in software (but still we are assuming that everything related to the GPIO settings of these pins have been done correctly).

Could it be a one off bad MCU? Do you have another board? Is this your own design board, or one of the evaluation kits?

It's difficult to come up with more ideas without looking at the hw schematics and the rest of the code, but for the time being, the part which has been shown here is correct.

Bruno

@Charles,

My writing (yesterday, 21:28) improperly spoke of a "signal ghosting" which occurred on (another) posting here - not this one!      (I am "released" from the "home" only briefly - that for (clearly) "good reason.")

Hi Charles,

My attempt @ humor may have (again) gone astray.    

Vendor's Ralph - and I - encountered a (likely) unwanted signal coupling issue - YET FOR AN ENTIRELY DIFFERENT POST!    It was my "screw-up" (my excuse was the hour) and after (still) moving our external warehouse - last night.   (which is on-going - we've much delicate equipment, lab-gear, sub-assemblies, power components etc.)

Now - as its early - might poster's use of "0x00" to clear (hopefully JUST) PC6 (or PC5 - I'm still unclear) prove too expansive - too BRUTAL?    We KNOW that Param 2 win "GPIO_PinWrite()" effectively limits the, "EXTENT of a WRITE SETTING" - but does it so limit the WRITE RESET (or CLEAR?)    Would not employing "/0x40" (or similar) provide a SAFER (i.e. more limited/targeted) Reset Approach?

(the "home" beckons - but thus far - I've "escaped...")    (and never do I "answer knocks on the door...")

Hi Charles,

I tried to change the board, same issues.

I tried to use a scope for PC5 and PC6 and they are not shorted.

It's happening something very weird. If I code:

GPIOPinWrite(GPIO_PORTC_BASE, GPIO_PIN_6, GPIO_PIN_6);
GPIOPinWrite(GPIO_PORTC_BASE, GPIO_PIN_6, 0x00);

my external device will stop to work.

If I code instead just: (basically without turning on the LED before)

GPIOPinWrite(GPIO_PORTC_BASE, GPIO_PIN_6, 0x00);

the external device IS working. This external device has got an interrupt PIN on PC5. There's no way he is connected to PC6.

And, funny fact, same thing happens with my red led, that is on PC7. If I try to turn it on and off, the external device will not work.