Connecting 16bit LCD: Port A vs port D or C. Same code but works differently

I have three stellaris launchpads and i can test ;) 
I try with all ports on stellaris launchpad blinking leds and a note that all ports only need this code to activate (and later write (GPIOPinWrite)): 

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOx);
GPIOPinTypeGPIOOutput(GPIO_PORTx_BASE, GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3|GPIO_PIN_4|GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7);

Only D7 and F0 (if i take out resistor from launchpad because is WAKE, but i not use F0) also need to unlock:
HWREG(GPIO_PORTx_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY_DD;
HWREG(GPIO_PORTx_BASE + GPIO_O_CR) = GPIO_PIN_x;

What is difference between use GPIODirModeSet and GPIOPadConfigSet or GPIOPinTypeGPIOOutput directly?

So, now, i clean all LCD pixels (make it black. is in portrait mode, so it should go from 0 to 320) and write red rectangle, my problem with other port than A for high byte of LCD is that ONLY make it black arround 50 lines (random grayscale on left side of screen and black on 50 lines in right) and red rectangle seems to be ok.
Also, i think that power modes are different because i note some flickering. I think some pin is blocked or delayed or i dont know... But i test and pins works well independently. 

any ideas?

These are complex devices - require great detail, effort and persistence.

Very much like the guidance TI Sean provided - yet cannot tell if you fully followed all of his advice. 

You've not chosen the easiest of projects - and getting things 99% right may still not produce the results you seek.  (devil very much in the details)

Now you ask about the difference between "GPIODirModeSet()" and "GPIOPinTypeGPIOOutput()" - and you really should be resourceful enough to uncover that answer yourself.  The fact that you've identified that as an issue shows a certain awareness (and cleverness) on your part - but you've failed to "follow thru" - and that is very much required.

One suspects that your IDE has a "search" facility - our IAR edition enables a "highlight" over a function - and then "search in files" takes us right to each/every mention/entry of that function.  And quickly - driverlib is revealed as the repository (home) for that function.  (and many other gpio functions) 

Quickly/easily we learn that, "GPIOPinTypeGPIOOutput()" makes calls both to "GPIOPadConfigSet()" and then to "GPIODirModeSet()".   So - as it encompasses multiple other needed functions - seems a superior choice!   

"GPIODirModeSet()" checks the chosen Port's validity - and then makes critical writes w/in "GPIO_O_DIR" & "GPIO_O_AFSEL".  The preamble to this DirModeSet function makes note that, "GPIOPadConfigSet()" must also be called so that the MCU pads may "propagate" the signal to the physical GPIO.  We note that "GPIOPinTypeGPIOOutput()" automates this multi-call process.  (Arduino is so, so much simpler!) 

When we hire/train new staff - we insist that they execute many such commands - and then note the effect of each w/in the key MCU Registers.  This is how you build understanding - independence - and mastery...

This explanation should provide you the tools should you "really" seek to explain why various Ports respond differently to identical functions.  Cross connecting MCU pins (on your board) was insane (no matter vendor's past defense) and your overcoming "locked" pins is too much - too soon - too distracting - from your central purpose... Armed with the info here - you should be able to repeat your earlier GPIO Output Tests - sequentially across different Ports - and resolve any inconsistency.  (hunch here is cable/connection - your measurement method/technique - not program nor MCU issue...)

Did you want - and are you willing - to "do battle" with such detail?  (a 15USD board may start to lose attractiveness when "ease of use" is factored in...)

Back to Sean's guides - you really, really must slowly toggle each/every pin which connects to your LCD.  Missing even one will prevent satisfactory operation.  (I know - as I've designed/sold 100K+ displays during my career)  How did you perform this testing?  It is not correct to test @ the MCU board's edge - even though that is convenient.  You must instead test directly at the input to the LCD - insuring that each/every connection "makes it."  A bad cable - a non-spec header (btw: Launchpad users have reported "narrow pins" on the header pins of some launchpads) or an intermittent contact/connection can easily defeat your (and our) efforts.

You give no detail re: your Lcd.  Along with 16 data bits there must be CS, RS, R/W, and strobes.  And you must get each/every one in full accordance with the Lcd spec.  Miss one - and the unsatisfactory results you (thus far) report are understandable.  Again - your task is demanding...

Certain displays require key signals to persist for minimal times - you must get this right too.  And it may be that multiple signals (input to the Lcd) may not rise or fall in unison - instead some must lead/lag critical others.  Lcd datasheet reveals.

(Ideas/detail) now @ your doorstep...

Thanx for your reply. Im ready to battle xD i use this LCD with pic32 but now i like to use with stellaris.
You forgot to mention this and i think is powerfull reason to throuble: A0 and A1 are JTAG pins and i think that GPIOPinTypeGPIOOutput disables JTAG function and other (GPIODirModeSet, GPIOPadConfigSet) doesnt.

I use SSD1289 LCD and connect RST and RD pullup, and CS to GND, RS to E3, WR to E1. Low data bus to port B and High data bus to A (But A have JTAG, this is the reason because i want to change, but any other full port are available, so i need to mix).

I remove R9 and R10 so, any pin are cross connected 

I started with library from SSD2119 provided by TI and it seems to look good. Only need to change some registers because horizontal and vertical are inverted in these displays.
All are connected and works, and data high are in port A.

Code to enable port high are this:

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
GPIODirModeSet(GPIO_PORTA_BASE,GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3|GPIO_PIN_4|GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7, GPIO_DIR_MODE_OUT);
GPIOPadConfigSet(GPIO_PORTA_BASE,GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3|GPIO_PIN_4|GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7, GPIO_STRENGTH_8MA,GPIO_PIN_TYPE_STD);

Code to write high are this:
GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3|GPIO_PIN_4|GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7, wh);

(wh are data: short type)

Code to enable port high are this:

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
GPIODirModeSet(GPIO_PORTA_BASE,GPIO_PIN_2|GPIO_PIN_3|GPIO_PIN_4|GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7, GPIO_DIR_MODE_OUT);
GPIOPadConfigSet(GPIO_PORTA_BASE,GPIO_PIN_2|GPIO_PIN_3|GPIO_PIN_4|GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7, GPIO_STRENGTH_8MA,GPIO_PIN_TYPE_STD);
GPIODirModeSet(GPIO_PORTD_BASE,GPIO_PIN_0|GPIO_PIN_1, GPIO_DIR_MODE_OUT);
GPIOPadConfigSet(GPIO_PORTD_BASE,GPIO_PIN_0|GPIO_PIN_1, GPIO_STRENGTH_8MA,GPIO_PIN_TYPE_STD);

Code to write high are this:

GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_2|GPIO_PIN_3|GPIO_PIN_4|GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7, wh);
GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_0|GPIO_PIN_1, wh); 

(wh are data: short type)

Now, i got the error last mentioned: the rectangle is shown good, but screen arent all black, only a few lines at right are black and other are grayscale random pixels. Also note some flickering. 

Oh wait...!!

I fix it shifting P0 and P1 (P0 are P1 and P1 are P0). I think code are OK... I try to find if the error was silkscreen or code (would not be the first fail, silkscreen fails with PE0, in board says P30)

You're right - dismissed PA0/1 as JTAG - has always been confined to Port_C (PC0-PC3).  (w/in the 6-8 Stellaris we've past used - dating to 2006/7)  That said - more modern Stellaris enforce a special "unlocking procedure" to "liberate" JTAG - and you do not report so doing.  I'll take quick look later - see if JTAG is "really" @ PA0/1.

Is it correct to "tie" CS to gnd?  Have worked w/many LCD Controllers over past 20+ years - normally CS "likes" to see an edge.  Controller timing chart should reveal.

Be aware that Stellaris can only output to one single (8 bit) Port at a time!  You need to perform 2 separate writes (to both high port and low port) and only then strobe that 16 bit data in.  Your use of wh (a short) causes uncertainty - as only a char (8 bits) may be passed via a Port write.  (or read)

You're silent as regards to "testing" signal level @ the Lcd.  (which insures cable and connections are all good)  Without this "basic" done/verified - we have strong chance of "chasing our tail" - not too high on our list...  You can both speed & ease such test by coding a "walking one" routine (load Port w/ 0x80 or 0x01 - and then shift at a 2-3 Sec. rate - the "1" will "visit" each/every Port Pin in an easily recognized sequence - insuring that each/every Port Pin will see both a high & low.  (and slowly enough that simple Led or DVM may successfully monitor)

The write strobe may be "at the margins."  Review Lcd data - you may wish to widen this strobe pulse to insure you meet the spec.  (expect that ARM will produce narrower pulse than PIC)

Are you not content w/past explanation (and recommendation) of GPIOPinTypeGPIOOutput()?  Believe that the case was quite well made in its favor - yet you persist in less efficient, multi-function calls - to yield same result!  (if you were my student - "D" grade results...)

If you had complete success using that PIC - then "modeling" that code and confirming connection integrity (everywhere!) has high chance of success.  Good luck...

Have made extra effort to find/review LX4F120H5QR datasheet - and as long suspected - your report of PA0/PA1 as JTAG is unfounded!   Why did you think this?  Follows - a true copy of subject MCU's datasheet - "Signals by Signal name:"

Signals are just as I previously described - PA0/PA1 have no JTAG link/responsibility. "Old Standards" PC0-PC3 continue in their JTAG role.

Further review shows that PA0/PA1 "default" instead into UART0.  (Table 10-1. GPIO Pins w/Non-Zero Reset Value)  This likely explains why you could not "harvest" PA0/PA1 as GPIO earlier - but your claim of JTAG was incorrect.  To return PA0/PA1 to GPIO Output you need to follow guidance of table 10-1 & table 10-3.  (appears that GPIOPCTL must be changed from 0x1 to 0x0 (table 1) and that GPIO Register must have AFSEL bit changed from 1 (Uart) to 0 (GPIO). (table 3)  Note that both you and TI guy missed this...

Hint: always good to review and then record multiple Register Settings of a properly functioning (to your expectations) Port - and then to compare each/every such setting w/Registers from the "failing" Port.

Devil in the detail w/any ARM MCU - they are far beyond PIC et al...

Your Verify Answer "tick" would be nice gesture...

Youre wrong:

Stellaris Launchpad Workbook.

Is a part of Stellaris In-Circuit Debug Interface

If you say so...  But doubtful - PA0/PA1 are NOT JTAG - as you continue to state (erroneously!)  They may have been usurped (look it up) by the debug MCU also emplaced on that board - but PA0/PA1 never have been - never will be JTAG.

Our styles are not compatible - (others will surely flock to your aid - I clearly tried)  wish you well...