2008-04-26 02:09 AM
STM3210B-eval problems
2011-05-17 03:31 AM
Hi everybody !
I have a LCD 128x64 graphic an i have the software in order to use it with the STM32. i had it in my last topic about the LCD. Now i plugged on the LCD on the connector CN12 and CN13 on the PE0...13 ! I download the software by the flash programming demonstrator using the UART1, i swith the SW0 and SW1 to ''0'' in order to launch on the user program. I push on reset and it works......sometimes !!! Indeed i have to push a several time to see something on the LCD. I think it is a ground problem. Indeed when i plug off the UART, i don't see anything on my LCD, but when it's plug on , i see something. I have put the ground of my LCD on the STM3210B-eval ! It's weard, and i don't understand why ! Perhaps I have to move some jumpers in order to use my LCD plugged on the connector CN12 and 13 ! Thank you !! :)2011-05-17 03:31 AM
Sorry, but my problem are not on my stm3210B card but i think they are in my head! i need coffee !!!
The probleme was i forgot a wire between the card and my LCD, the Reset wire. Sorry !! I go take a coffee and sleep a lot ;)2011-05-17 03:31 AM
Lcd Users: (more lengthy than I intended - trust many will find useful)
We can best assist when symptoms are presented in more detail. I am guessing that yours is a ''contrast'' problem - likely caused by insufficient negative voltage on the Lcd's Vo pin. Here are general Lcd Diagnostics - intended to organize your attack - but written to be of use to many: (I am past founder of intl Lcd firm) a) Contrast: Your software/timings can be perfect but if you have incorrect contrast voltage your display may be too light or too dark. Most 128x64 Graphic Lcds require a negative bias on the contrast pin. As this voltage moves toward 0V (ground) the contrast will diminish. As the voltage is made more negative the dot-field will become darker. Too much negative will also degrade contrast (the background dots will become visible) The Lcd's Vo spec is the ''controlling legal precedent'' here. Have you supplied adequate negative voltage? (2-3 mA should suffice) If your screen is briefly visible - and then loses contrast - it is likely that your negative supply is improperly set or inadequate. Usually a 10K pot's wiper feeds the contrast pin. You can hook one end to 3V3 and the other to your negative supply. CAUTION - read and comply with your spec - too much Negative V can ''kill'' the Lcd. Note: Most 128x64 Lcds require 5V - not 3V3. It is usually ok to drive the bus & control sigs with 3V3 levels - but if you provide the same 3V3 to Vdd you will drastically reduce the Lcd's contrast. (sometimes you can ''cure'' this by increasing the Negative voltage to the Vo pin - but DO Stay WITHIN Lcd's spec) I don't recall if you can get 5V from CN12/13 of ST's nice eval board. The effect you describe with your Uart suggests that someway/somehow you are acquiring ''phantom'' negative V from the Uart. Check and confirm the voltage level on Lcd's Vo (contrast pin) both on power_up and after the Lcd ''dims.'' b) Signal Timing: Historically Samsung provided most of the control ICs for this class small Graphic Lcd. This production has recently shifted - there are reports of some timing differences. Increase your write strobe by a factor of 3-5X and increase your Set Up and Hold times by 3X. Once you're working you can ''dial down'' - but I'd advise staying with a safety margin. Lcd control ICs have ''execution times'' which varies by function. This means that you must provide suitable ''delays'' after each command. c) Software: Your code is likely written again for the Samsung. Most chips have continued that - the fact that sometimes you do work pretty much gets your software ''off the hook.'' It can't hurt to ''test'' each of the Lcd chip's ''commands'' to confirm they perform as you expect. You must ALWAYS Initialize your Graphic Lcd. Your manual should list the commands and perhaps their order. Most Lcds of this size include commands to Turn ON and Turn OFF the Lcd. Are you certain that you have not, inadvertently sent a Turn OFF command? Addressing the Lcd properly is required. These Lcds usually place your byte data as 8 pixel vertical stripes with D7(msb) bottom. It is usual that each write will ''auto-increment'' the display cursor (invisible) allowing you to ''machine-gun'' in data with only 1 address command per 8 pixel ''row.'' You have to send a new address command to engage each of the 7 rows of these 64 pixel tall displays. Lastly insure that your software provides sufficient ''post command'' delays - so that data following is not lost/garbled. We always ''test'' our understanding of new displays by: 1) confirming all power and bias levels WITHOUT the display 2) write/confirm your initialization code WITHOUT the Lcd ''connected and waiting''. 3) write code snippets so that you can address and then write to Upper Left, Bottom Right of the screen. Once you can do this you are ''home-free'' - your only battle then is Font Generation, Image management, Selective Display Clears, and Character Generators producing larger fonts which ''intrude'' into multiple, vertical bytes. A systematic approach should get your Lcd ''on the air'' fastest - Graphic software is the really FUN part. Hope that you/forum users find this writing of use...2011-05-17 03:31 AM
I would like to add a few extra suggestions. I've recently got a 98 by 64 pixel COG LCD working on my custom STM32 board. The LCD uses the SAMSUNG KS0724 driver chip.
It can be incredibly frustrating if these LCDs don't work the first time - there are so many things that can go wrong. Be careful of the state of pins attached to the LCD during the initialisation process. The LCD normally consumes less than a few hundred microamps, and I power it directly from an IO pin (VLCD). But if VLCD is low and any other LCD pins are high (eg. Chip select, SPI pins) then the LCD can draw tens of milliamps. Best to step thru the initialisation process and check that the current consumption doesn't do anything startling as the pins change. Also, if you are manually sending data to the LCD via the SPI, remember to use the SPI_FLAG_BSY (not SPI_FLAG_TXE) to determine that the data has been sent - before changing CS or RS signals. I refresh the display from an array of bytes that I DMA to the LCD. The array is also accessible using Bit banding. Bit banding can be sped up by using a lookup table for generating some of the offsets eg. #define Set_LCD_BB(x, y) (lcd_bit_band_display[ (x<(where y_offset array is calculated at start-up) To get the best efficiency, some drawing tasks are best done by using Bit banding, other tasks are best done by writing directly to the byte array (eg. drawing characters). To show how cantankerous LCDs can be: my LCD seems to work fine most of the time, but if I disconnect the power for several hours the display doesn't start up on the first attempt. Cycle the power or do a reset and the display starts. Probably one of the intialisation delays needs to doubled or tripled - but I want know which one is causing the problem and it's going to be a pain to debug. Greg.2011-05-17 03:31 AM
Thanks greg_stm - valuable info for those choosing the new, ''improved''
serial bus Lcds. Have heard similar reports. (and worse) I suggest that you confirm your experience across a 3-5 additional Lcd population. It would be safer IF you could locate (then test) a 2nd source, as well. The intermittent conditions you describe are maddening. (and demoralizing to staff) The only thing ''standard'' about Graphic Lcds is that there are NO ''standards!'' Lcds are designed/built for one/few key clients - and only then offered to we ''unwashed.'' We have NOT spoken about the ''joy'' of migrating Graphic software among different size Lcds/control ICs -an additional JOY. It may be best for our forum users to ''stick with multi-sourced'' mainstream Graphic Lcds - and employ the ''exotics'' ONLY after your sales volume is proven.