New STM32H747-DISCO example problems.

[ACapo.1]

Hi There,

I have a new STM32H747-DISCO here.

The board came without the demo flashed on it, also the demo can not be flashed, see here: https://community.st.com/s/question/0D53W00002ASl3lSAD/stm32h747-discovery-blank

Most of the examples in the cube package concerning the lcd do not work, see here: https://community.st.com/s/question/0D53W00002A3uJaSAJ/stm32h747-lcd-display-issue

The BSP example doesn't build, the project import looks wonky, links are incorrect.

Some stemwin examples that build will not flash, for example STemWin_acceleration_CM7.

As the linked problems have also been posted very recently is there a new revision of this board that is not compatible with the examples?

I have tried STMCubeIde 1.11 and 1.12, also tried on windows, linux and even a Mac.

Exact same issues on all of them.

Anyone any ideas how to progress here as basically very little is working!

[Tesla DeLorean]

>>As the linked problems have also been posted very recently is there a new revision of this board that is not compatible with the examples?

Good question, let's start by identifying which board revision(s) you have, it should be marked on the board, and with stickers, usually. Check the main board, and the screen board. Check the README files for any special notes or command line defines/options unique to specific board parings.

Not sure the screen image on the other thread is due to the "screen", or the memory used for the frame-buffer, or the LTDC/DSI timings, the data paths here are very intolerant of incorrect settings/configuration. Things can escalate quickly.

If some examples work and others don't, it's probably not the hardware, but a build, compile or optimization settings. Let's identify a sub-set of things that are and are not working, and then let's look at the common mode of failure and differences.

[ACapo.1]

Thanks for the reply.

I have CPN:STM32H747I-DISCO FG: DK32H747I$AT1 on a white sticker.

On the images I can find on the net that second FG bit is not there.

I think I have tracked down why some are not displaying, they are using the SDRAM for the frame buffer,

Also the ones I am having trouble flashing also use the SDRAM, although I'm not sure this is related.

In the debugger I cannot read from the SDRAM: 0xD0000000

Do you know if there is a way of testing if the SDRAM is working?

[ACapo.1]

Ok, nothing to do with SDRAM.

The examples that are working use DSI command mode, the ones that don't work don't seem to use it.

I need to read up on this...

[ACapo.1]

I have added an issue to GH, maybe someone can help us there: https://github.com/STMicroelectronics/STM32CubeH7/issues/254

[ACapo.1]

Concerning the examples that won't flash, this does seem to be connected to SDRAM.

For examples that set up a link section for the SDRAM and then use them like:

MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
RAM (xrw) : ORIGIN = 0x24000000, LENGTH = 512K
ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
SDRAM (xrw) : ORIGIN = 0xD0300000, LENGTH = 4900K
}

U32 aMemory[GUI_NUMBYTES / 4] __attribute__((section(".GUI_NUMBYTES_section")));

When the IDE or the programmer try to flash the elf/hex they are actually trying to write that section for some reason:

```

09:52:49 : Number of segments: 2

09:52:49 : segment[0]: address= 0x8000000, size= 0xE7AAC

09:52:49 : segment[1]: address= 0xD0300000, size= 0x4C9000

...

09:53:19 : Erasing memory corresponding to segment 1:

09:53:19 : Download in Progress:

09:53:24 : Error: failed to download Segment[1]

09:53:24 : Error: failed to download the File

```

Any idea why it is doing this?

[ACapo.1]

ok, this fixes it:

.GUI_NUMBYTES_section (NOLOAD) : { *(.GUI_NUMBYTES_section) } >SDRAM

Is it just me or does no one use these examples!

[BillG]

@ACapo.1​ 

Is there a way to tell if the display is working at all - I get nothing on mine. I was able to flash the demo application without issue. I just get no display at all. Did yours at least show pixel activity when you powered it on?

Thanks - Also I apologize if I am not supposed to "@" message you. New here.

[ACapo.1]

Hi Bill,

If you build and flash one of the DSI command mode examples then you should see the screen jump into life.

Cheers

Andy

[Sarra.S]

Hello all,

Thank you for bringing this issue to our attention.

I confirm the issue and I reported Internally.

Internal ticket number: 147459 (This is an internal tracking number and is not accessible or usable by customers).

Sarra

[JSext.1]

Sarra, just wondering if there is any update on this as I have purchased a number of new boards after completing work on an older one. As stated previously, the new boards only work if I change the screen over from my older board. Any update would be helpful. Regards, James

[MOBEJ]

Hello ,

The fix is available on GitHub :

https://github.com/STMicroelectronics/STM32CubeH7/commit/1c84713102f8509deb79ae14db8dbb104c17c45e#diff-8a5b12f7040dfb560c495dc0a1213725ba939bf19d531dd1e97067b6a1a79ec0

In fact , LCD DSI MB1166-A9 delivered with latest version of STM32H747I-DISCO/ boards come based on LCD FGRIDA FRD400B25025-A-CTK instead of FRD397B25009-D-CTK.

Now the firmware is updated , you just need to enable the right hardware component as defined in stm32h747i_discovery_conf.h file and add the new component library (NT35510) in your project .

/* IMPORTANT: One of the following flags must be enabled in stm32h747i_discovery_conf.h file */

/* options in order to select the target daughter board revision connected on STM32H747I DISCOVERY : !!!!!!!!!! */

/* USE_LCD_CTRL_OTM8009A */ /* Applicable for all LCD daughter boards (MB1166) except for Rev -A09 */

/* USE_LCD_CTRL_NT35510 */ /* Applicable only for LCD daughter boards (MB1166) Rev -A09 */

[ACapo.1]

Hi @MOEZBEJ​ 

Thanks for the info, I will try it later today.

My LCD does have a sticker with MB1166-A03 A225302336 though, are we thinking the sticker is incorrect?

[MOBEJ]

hello @ACapo.1​ ,

your LCD MB1166-A03 A225302336  is also with the LCD FGRIDA FRD400B25025-A-CTK , so you can use this fix

Thank you