Jump to content

LCD does not start on STM32F4 board


Recommended Posts

Hello guys,

 

I am facing a stupid problem with a LCD (4x20) connected to the RTP-MIDI core... It simply does not start. I am sure that I forgot something somewhere, but I can't find what

 

I have verified all lines under the bootloader using the testlcdpin command, everything is fine

I have set the display size to 4 x 20 in the bootloader

 

In my app, in the APP_Background, I have put this sequence :

 

MIOS32_LCD_Init(0);

MIOS32_LCD_Clear();

while (1) {

  MIOS32_LCD_CursorSet (0,0);

  MIOS32_LCD_PrintFormattedString ("TEST");

}

 

but my display clearly does not even initialize (I see the "default" squares when I set the contrast to the max). Moreover, I was expecting activity on pins PA8, PD3 and PD6... but nothing at all (checked with my oscilloscope), like if the LCD driver did not start at all.

 

What did I miss ?

Edited by BEBDigitalAudio
Link to post
Share on other sites

Problem partly solved...

The display was not correctly activated in the bootloader.

 

But three things look strange to me :

- I have completely reloaded the bootloader using ST-LINK, and when I type help in the bootloader, I see that the current LCD type is 0 (CLCD). If I just define the other parameters, then store them, the display is not initialized. I had to set the lcd_type to 1, then back to 0, then store to see the display being initialized

 

- I get a wrong display both in bootloader and application: the cursor does not move on the expected line. In bootloader, I see "Bootloader 1.015 ©" on the first line and "2014 T.Klose" on the second line, which is not correct (the "©" shall be on the second line). I made a test with two different displays (2x20 and 4x20) : same result. I also get the same problem with my application (text from the second line appears at the end of first line)

 

- when I select 4 for lcd_height, it does not seem to work; my display still reacts as a 2x20

 

Any idea of the possible reasons for that ?

Link to post
Share on other sites

I don't know about the RTP or the STM32F4 board but I did use a 4x20 line display on one of my projects on the LPC hardware.  The only difference as far as the display is concerned are the start addresses of the lines.  But there are buffers in the LCD task that have to be allocated for the text being written.  I haven't investigated where this happens for a long time but what worked for me was to add:

"# define SCS_LCD_MAX_LINES    4"  to the mios32_config.h file found in your apps directory. 

 

Pete

Link to post
Share on other sites

Yes, I second Pete's hint: the cursor addresses are different compared to "common" LCD sizes.

 

But the cursor mapping has to be done at the application side, e.g. via MIOS32_LCD_CursorMapSet

See also: http://www.midibox.org/mios32/manual/group___m_i_o_s32___l_c_d.html#g1d34ecba2a96a80c9bb8b1ee757b4fdf

 

So: if your application doesn't use $MIOS32_PATH/modules/scs, the proposed define won't help.

 

In your application you can either do this statically by calling MIOS32_LCD_CursorMapSet w/o conditions, or you could request the configured LCD dimensions from the bootloader section.

 

Use this MIOS32_LCD_ParametersGet function for this purpose:

http://www.midibox.org/mios32/manual/group___m_i_o_s32___l_c_d.html#gd2ee61cebc910769c800afe4c6e281bd

 

This will return following parameters:

http://www.midibox.org/mios32/manual/structmios32__lcd__parameters__t.html

 

Best Regards, Thorsten.

Link to post
Share on other sites

I just when through the software that I had modified and found that I was using calls to functions in the trunk/modules/scs/scs_lcd.c file.  This software uses a storage array called lcd_buffer[][] which was what I remembered.  This is where the SCS_LCD_MAX_LINES variable is used.   It so happens that the routines you are using are NOT using these and shouldn't be a problem as long as your software is not running the normal SCS screen functions.

 

Pete 

Link to post
Share on other sites

Hi Thorsten,

thanks for these explanation, it's more clear for me now.

 

However, I still have the strange problem with the bootloader, even with the 2x20 display. Here is what I did :

- flash the bootloader in STM32F4DISCOVERY (to be sure it's completely initialized) and cycle power to restart completely

- the LCD now shows the "default" state (one line of black squares on top)

- when I type help in MIOS Studio, it says that current lcd_type is 0x00, current lcd_num_x is 2, current lcd_num_y is 1, lcd_width is 16 and lcd_height is 2. This is normal (default values when bootloader is flashed)

 

Now, I type the following commands to activate my 2x20 display attached to J15A

- set lcd_num_x 1

- set lcd_width 20

- set lcd_height 2

- store

 

First store command is rejected : bootloader says "Failed to store new settings"

Second store command is accepted. I see "New settings stored", "Initialize LCD#1"

 

Since I see only one LCD being initialized (LCD is ignored) I assume the bootloader understood the parameters, telling there is only one display

But the LCD is not displaying the READY message...

 

Typing help now shows this:

- lcd_type 0x00

- lcd_num_x 1

- lcd_num_y 1

- lcd_width 20

- lcd_height 2

 

which are the correct parameters for my 2x20 LCD (maybe I am wrong ?)

 

Now, if I type set lcd_type 1, the LCD shows "LCD #1.1         READ" (so the display is now initialized properly, but second line does not appear correctly)

Setting back to lcd_type 0 works too (but ignored if type was not 1 before)

But the display does not initialize properly until I force it to type 1 or 0 even if it is displayed as a type 0

 

Here are some pictures of my 2x20 display after this init sequence, with the broken "return" (beginning of line 2 is displayed at 17th character of first line, which makes me think that there is a problem handling the 20 characters width)

 

Benoit

Link to post
Share on other sites

Hi Benoit,

 

 

First store command is rejected : bootloader says "Failed to store new settings"

 

there is a workaround for this in following (unreleased) version:

http://www.ucapps.de/mios32/mios32_bootloader_v1_016.zip

(store command will be retried if flash operation failed - I guess that this is related to flash protection, but haven't debugged this further. With the retry the store command will work reliable)

 

 

LCD: it's very likely a hardware issue.

LCD isn't correctly initialized after power-on, and in your pictures it looks like the second line will never be written.

 

This indicates, that the D6 pin is always 0

Check it with the scope. If it doesn't toggle than my assumption is correct and you know where to continue with debugging.

 

Best Regards, Thorsten.

Link to post
Share on other sites

Thanks Thorsten,

I will try this new version tomorrow.

 

I have checked all pins with a voltmeter using testlcdpin command, and the voltage was going correctly between 0 and 5V. By the way, I got the same result with 3 different LCD models.

I will do another check, maybe the flat cable is cut somewhere and gives bad contacts.

 

I will do a test with my logic analyzer too, I will post the traces if you want

 

Benoit

Link to post
Share on other sites

Alright.

 

Note that the new bootloader won't change the LCD behaviour at your side.

I'm sure that this is a HW issue, because I've checked the SW drivers with various CLCDs and GLCDs some time ago, and you are the first guy who reported such an effect.

 

Best Regards, Thorsten.

Link to post
Share on other sites

Just verified once again with testlcdpin : D6 (and all other lines) are controlled as expected (verified directly at display connector, not on MBHP of course)

Checked with the scope : D6 is toggling all the time as expected when I run a program talking continuously to the display

 

Thorsten, following your idea of a problem with D6 (which would prevent the DDRAM address to go to 0x40 and then sticking to the first line), I made a simple program writing the following characters : <=>?@ABCD. The first four have D6 set to 0, the last four have D6 set to 1. They are displayed as expected, so I am quite sure that D6 line reaches the display correctly (the characters would be garbled otherwise)

 

I will continue my investigations with the logic analyzer today, to see if I can find anything else.

 

Benoit

Edited by BEBDigitalAudio
Link to post
Share on other sites

Root cause of the problem found and problem solved...

 

Using my logic analyzer, I have been able to see that initialization sequence of CLCD_DOG was correct, but data stream for CLCD was corrupted.

Looking in app_lcd.c source code, I saw that CLCD uses open-drain, but CLCD_DOG uses push-pull...

 

I remembered that I changed the resistors going to J15A and J15B to 10k... and this cause all the troubles :shocked: probably because the signal does not go back to 1 fast enough when the open drain switches off.

I just replaced R5/R6/R7/R8 by 1k (value given on TK's schematics) and now the LCD works like a charm. I will update the schematics of the RTP-MIDI MBHP to reflect this requirement.

 

For TK : I tested bootloader V1.16, no more problem to store the display configuration data. The store command works every time now

 

Thanks to all (and especially Thorsten) for your help on this problem

 

Benoit

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...