LCD does not start on STM32F4 board

MIOS programming (C)
,
1

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 ?

2

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 ?

3

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

4

Hi Pete,

 

thanks for your suggestion, I will try it tomorrow

 

Benoit

5

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](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](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](http://www.midibox.org/mios32/manual/structmios32 lcd parameters__t.html)

 

Best Regards, Thorsten.

6

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 

7

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

8

Better with pics…

 

<___base_url___>/gallery/album/261-/?do=embed

9

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.

10

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

11

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.

12

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

Yes, I understood that this was only solving the potential Flash initialization problem

 

I will check today the whole cabling both with the scope and the logic analyzer, to see what could be wrong.

13

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

14

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

15

Fine! :slight_smile:

 

Yes, 10k pull-ups are too weak for the LCD signals, therefore I recommend 1k

 

Best Regards, Thorsten.

16

BTW, can an admin change the title of this topic to (solved) ?

Thanks

 

Benoit

17

I think you can do that yourself by editing the first post.