No Display on EB-LM4F120-L35 Boosterpack

Hi Alastair,

I've used Kentec320x240x16_SSD2119 driver, in the code I used the Kentec320x240x16_SSD2119Init() does not enable the ports it uses, they must be enabled before hand with SysCtlPeripheralEnable() calls. 

Alastair Cardwell said:

Probing the pins with an oscilloscope shows that they are changing state.

This suggests that - although code is not shown - OP has in fact enabled "some" critical ports.  (i.e. those he has probed...)

Does your silence wrt, "Delay post CLS (ClrScreen())" mean that you do not believe such delay helpful - even mandatory?

Thanks for the suggestions.

@cb1
I tried adding a delay as suggested but it didn't make any difference. I have also stepped through the code in debug mode which I presume would negate any timing issues.

@Paul Scullin
The version of the driver library that I am using does initialise the ports within Kentec320x240x16_SSD2119Init();

I suspect that it may be a faulty unit given that none of the provided demo code works. I want to be sure that I haven't missed something simple before I get it replaced.

Assume that this display provides 8 bit parallel port + control lines.  Likely will cost time/effort to replace.

Suggest that you confirm that proper signals are at each/every control line.  (/RD, /WR, /CS, /RS-A0 are most critical)  Don't know if you cable to the display - or if it has a mating header - and simply "plugs in."  All cables are suspect.  You should probe for signals @ the display side - not MCU side.  (which tests both cable integrity & signal generation)

Most such displays "come up" w/disordered pixels reflecting the unintialized GRAM content.  May assist if you set breakpoint @ ClrScreen() - does the pixel field come into view at all?  Suggest that you then run the ClrScreen() function - often this will prevent the disordered state from causing damage.

Review "Kentec320x240x16_SSD2119Init();" - for this to succeed both the MCU and the TFT must be fully/properly initialized.  (we don't know if this particular display was targeted for your exact MCU - thus the pinouts may differ - cannot hurt for you to systematically check)

Makes sense to report your distress to hallowed display maker - ask them to confirm there are no/minimal "gotchas" in your exact application.  This is a fairly new development - often these are not quite, "Ready for Gov't work..."

@cb1
Thanks again for taking the time to give advice. 

At this point I am as sure as I can be that it is a faulty. The Booster Pack is manufactured by Kentec Display for the Stellaris Launchpad and plugs directly onto the pin headers.  They also provide example code. As best I can tell using a 2 channel scope all the i/o lines are changing state at the correct times.  

I will return it to the supplier for a replacement.

Hi, I am having exactly the same problem! I find it hard to believe both units are defective. Don't know about you but had to jump through hoops to even find the demo prog files. Even the project specified in the Lab videos was missing/incomplete. I'm thinking there is some problem with the code as supplied by Ti. I've very disappointed so far as this is the main reason I got the BP in the first place. Bet you are too. Hope you can get it working!

cb1_mobile said:

Makes sense to report your distress to hallowed display maker - ask them to confirm there are no/minimal "gotchas" in your exact application.

I've long been in display & MCU field - I'd get the display maker far more involved.   Suspect this is too new to have really registered w/forum's MCU experts - display vendor is a far better target...  (as alternative - I've suggested "step by step" troubleshooting procedure - which will at minimum test/verify the "basics.")

It is strange that two boards would exhibit the same issue. I believe the demo code was supplied by Kentec and it is also available for download from their website. If I remember this I mentioned in either the workshop video or the workbook. It apparently did work at some point as the workshop video shows it running. I suppose some revision on either the Launchpad, Stellarisware library or the display itself could be causing an issue.

I have a replacement on the way so will report back as to whether it works or not.

@John
What is the quality of your unit like? The one I sent back had solder splashed onto the plastic of the header connectors. There also appeared to be small pieces of solder over the board in places. I did carefully check under a magnifier but didn’t see any shorts. I didn’t mention this before as I wanted to concentrate on something I may have missed rather than any potential issues with the board.

Thanks for the response! I just do this stuff for "fun" (sometimes!), it's not my "job" and, as such, do not have the depth of knowledge necessary to have a productive discussion with the vendor. Basically I don't know the right questions to ask! Ti indicated there was a working example that I could build on but that doesn't seem to be the case. I don't pretend to be an expert in this platform or language and am not interested in reinventing the wheel. I'll put some more time into it but if no other resources become available will probably sell it and look for alternatives.

There is some flux buildup on one of the headers and yes some of the solder looks a little rough in that area but overall it looks good. I've verified that the touch screen is working. I got mine from Newark- how about you? There really seems to be limited resources available and the the ones that are are not particularly  "friendly" to casual users such as me. I'll be very interested to see if you have success with a replacement or otherwise! Jack

Jack Harper said:

do not have the depth of knowledge necessary to have a productive discussion

May I respectfully disagree?  Both you and the other poster have adequately "framed" a common "issue" - and I would bet that a brief email to the display vendor would prove beneficial.  Simply repeat the basics: model number of your purchase, use of TI launchpad, identify the TI software used (file name, ver, date) and your resulting - "blank screen" results. 

Any committed display vendor should have - at the ready - a simple check-list which should guide you to proper operation.  Part is sufficiently "new" that this hasn't been "fine-tuned" yet - not included with your package - but should be forthcoming. 

Two out of two (known) failures is something that should motivate/concern the display vendor - they have a vested interest in your satisfaction.  (And - they stand to gain from the "universal" nature of your problem solution...)

You could be, "On the Air" with a simple, single software "bit-flip!"      Suspect this may be a more rewarding approach...

I have received the replacement display and the results are as before, just a white screen when tested with the demo code.

As cb1 suggested I have emailed the manufacturer explaining what is happening and asking for their advice. I will keep the thread updated as to the outcome.

Good for you - believe that is your best course of action. 

Should you not have resonse by close of business (cob) tomorrow - if you'd link both to display datasheet and the exact TI SW you're using - I'll review during the weekend - see if something reveals. 

While unfortunate that 3 of 3 are DOA - clearly the number is much higher - as not everyone will make the effort you two have...

Final thought - should that display have been targeted for another, or earlier MCU board - this suggests the possibility of signal and/or SW "scrambling" (i.e. "lost in translation") which usually is a quick, painless and lasting fix...  If you provide proper links - I'll do my best...

cb1- said:

I'd ohm out each/every signal lead between the launch and the remote display board.

This was my initial response (back on Feb 16)  - appears it may merit a, Verified Answer 'tick" as well...

Glad you accepted advice - I am concerned about the "long-term" reliability of that "connection."

Update: @Stellaris Dave - Thank you, Sir.  Appreciate both your kindness - and astuteness...

That's fantastic- who knew? Hopefully that's my problem too. Will check it out this weekend.

Hi Alastair,

I'm trying to run your code example but am running into issues such as these unresolved symbol errors.

I'll be the first to admit that I am pretty new to C/C++ as a language and very new to the CCS GUI. 

I have tried to solve this problem a number of ways and searched for a general description of the fundamental nature of the problem to no avail.

If you could provide some guidance on basic steps needed to resolve problems of this type it would be greatly appreciated.

Thanks

Jack

Description Resource Path Location Type
#10010 errors encountered during linking; "test.out" not built test C/C++ Problem
<a href="file:/E:/TI/ccsv5/tools/compiler/dmed/HTML/10234.html">#10234-D</a> unresolved symbols remain test C/C++ Problem
unresolved symbol g_sFontCmss30b, first referenced in ./main.obj test C/C++ Problem
unresolved symbol g_sKentec320x240x16_SSD2119, first referenced in ./main.obj test C/C++ Problem
unresolved symbol GrContextFontSet, first referenced in ./main.obj test C/C++ Problem
unresolved symbol GrContextInit, first referenced in ./main.obj test C/C++ Problem
unresolved symbol GrRectDraw, first referenced in ./main.obj test C/C++ Problem
unresolved symbol GrRectFill, first referenced in ./main.obj test C/C++ Problem
unresolved symbol GrStringDraw, first referenced in ./main.obj test C/C++ Problem
unresolved symbol Kentec320x240x16_SSD2119Init, first referenced in ./main.obj test C/C++ Problem
unresolved symbol SysCtlClockGet, first referenced in ./main.obj test C/C++ Problem
unresolved symbol SysCtlClockSet, first referenced in ./main.obj test C/C++ Problem
unresolved symbol SysCtlDelay, first referenced in ./main.obj test C/C++ Problem

Hi Jack

I am fairly new to C and CCS as well so someone else may be able to elaborate a bit more.
I think the problem is that some of the included files cannot be found when compiling.

I created the code following the instruction for workshop 10. It reuses the existing grlib_demo project by disabling the build of grlib_demo.c and adding a new file so all the setup is already done.

@cb1
I went to verify your post on 16^th but Stellaris Dave has beat be to it.