TouchGFX Template for RVA35HI + H563ZI Template for REV1.0 of display

[CharanVis]

Hi there, 

I was trying to use the TouchGFX Designer Template for the H563ZI dev board with the RVA35HI display. However I noticed that I have REV1.0 of the display whereas the template that is generated is for REV1.1.

I tried configuring the pin connections through the .ioc files by referring to respective version datasheet but so far no luck. It would of great help if there was any way in which I can be given the template for the display version that I've got.

Any help would be really appreciated.

Cheers

[GaetanGodart]

Hello @CharanVis ,

What happens if you try to use an older version of the provided TBS :

Regards,

[CharanVis]

Hello @GaetanGodart,

I did try using v3.0.0, still the same issue. The loader that is generated is for REV1.1 and the ioc configurations also seem to match that of REV1.1 when cross checking with the datasheet...

[CharanVis]

@GaetanGodart and @Osman SOYKURT, I was wondering if I would somehow be able to access the template for REV1.0 of the display. Our project has been delayed by quite an amount due to a lot of complications.

We initially had the U575ZI-Q development board for which there was no template. As a result we got the H563ZI development board. Tried getting the demo code from TouchGFX Designer to work but failed to do so. We also tried using the U575ZIQ + RVA35HI template once it was out and same results as before :(

Only after some amount of debugging, we found out that we have REV1.0 of the display whereas the template (all versions) are for REV1.1 of the display. Any help regarding this would be really appreciated. The display is a really important part of our project and we can't afford further delays either. Looking forward to hearing back from you.

Note: Here's a detailed thread made on the problems that we faced ( We also tried the same steps with the H563ZI board)

https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/u575zi-q-dev-board-rva35hi-display-touchgfx-error-failed-to/m-p/749198

Please let me know if there's further information that might be needed and please do consider this to be of priority. Cheers

[GaetanGodart]

Hello @CharanVis ,

It seems we have not made a template (we call that a TBS for TouchGFX Board Setup) for the rev10.0, if we had, it should be a previous version of the TBS.

---

Tried getting the demo code from TouchGFX Designer to work but failed to do so. We also tried using the U575ZIQ + RVA35HI template

---

What do you mean by "demo code" and "template".

It seems that the issue preventing you from having a plug and play option is the wrong version of the display, you should then get a rev1.1. This could be a solution if you only want to make a demo (and therefore did not buy a lot of rev1.0 already).

On the other hand, you could use the rev1.0 and make your own TBS, you could maybe use the rev1.1 TBS as a starting point. This won't be a plug and play solution as you would have to make a TBS but at least you won't have to wait for delivery and can reuse your rev1.0.

Regards,

[mathiasmarkussen]

I can see you have had issues with the external loader, which you seem to have (partially?) solved with a loader you found on Riverdis github repository. Have you been able to confirm that the flash actually contains what you expect after flashing with that loader?

Have you tried to create a test project in TouchGFX (for RVA35 1.1) with all the assets in internal flash?

This would eliminate the external flash as an error source for both writing and reading. I believe confirming that you can get an image on the display should be our highest priority at this point.

[CharanVis]

Hi @mathiasmarkussen @GaetanGodart , thank you for your quick responses :)

Just a couple clarifications:

1) We have ordered another display from Mouser Electronics recently. But there's still the chance that it might be REV1.0 of the display rather than REV1.1. So until then, we are going to have a go at this

2) I went through the datasheet for the RVA35HI display (the initial release vs the latest updates) and found a couple changes made to the PCB. A number of the pin connections of the connectors (CN7, CN8, CN9, CN10) have been changed between the two versions. These are the datasheets I was referring to:

https://nz.mouser.com/datasheet/2/1021/DS_RVA35HI_NUCLEO144A_Rev_1_0-3473845.pdf
https://download.riverdi.com/RVA35HI-NUCLEO144A/DS_RVA35HI-NUCLEO144A_Rev.1.2.pdf

3) Using the external loader from Riverdi's GitHub repository, I successfully flashed the external memory segments. However, I still need to confirm if the flash contains the expected data. It's worth noting that due to differences in pin configurations between the two versions, the .ioc pin configuration in the TBS doesn't align with the expected connections for the REV1.0 display. As a result, there’s a significant chance that the flashing may not have been accurate.

4) The data bus configurations for REV1.0 and REV1.1 of the display are different along with some other signals. In REV1.0, the data bus pins are arranged differently compared to REV1.1. We’re currently trying to update the .ioc pin settings to match REV1.0, but the differences in how the data bus is configured are causing some challenges.


Will keep you all updated as I progress. So until then, can we have this post open for discussion still?

Thank you once again for your help :) Really appreciate it

[GaetanGodart]

Hello @CharanVis ,

Yes, we can keep on exchanging about the issue on this thread! :smiling_face_with_smiling_eyes:

Regards,

[CharanVis]

Hello @GaetanGodart @mathiasmarkussen 

Behold, our creation:

How we are approaching this:

1) We decided to not change the TBS for the RVA35HI + H563ZI, rather adapt the connections off REV1.0 to match that of the expected connections for REV1.1 of the display.

2) This involved spotting the differences between the mappings of the respective versions and using female-male jumper cable connections from the display to the dev board. PS: Have attached the table we formulated for the above

3) Some key points to note is that, in the TBS generated, we could see up-to 8 Data Buses in total (ordered from DB0-DB7), whereas in the pin connections for REV1.0 of the display, there were more than 8 Data Buses attached to the connectors (CN7-CN12). What we decided to do was to simply ignore all the Data Buses after DB7 since .ioc file for the TBS expected only upto DB7. If what I have said so far is not clear, please feel free to ask for clarification :)

Here's the link to the datasheets for your reference:
REV1.0 
REV1.1

4) Some good news: We were able to flash the target (both internal and external) through TouchGFX Designer without having to modify the TBS itself. Here's the console output from TouchGFX Designer:

 Flash
        make -f ../gcc/Makefile flash
        Reading TouchGFX/application.config
        Reading TouchGFX/target.config
        Linking TouchGFX/build/bin/target.elf
        Producing additional output formats...
          target.hex   - Combined internal+external hex
          intflash.elf - Internal flash, elf debug
          intflash.hex - Internal flash, hex
              -------------------------------------------------------------------
                               STM32CubeProgrammer v2.18.0                  
              -------------------------------------------------------------------
        
        ST-LINK SN  : 003D00223433511037363934
        ST-LINK FW  : V3J15M7
        Board       : NUCLEO-H563ZI
        Voltage     : 3.30V
        SWD freq    : 8000 KHz
        Connect mode: Normal
        Reset mode  : Software reset
        Device ID   : 0x484
        Revision ID : Rev X
        Device name : STM32H56x/573
        Flash size  : 2 MBytes
        Device type : MCU
        Device CPU  : Cortex-M33
        BL Version  : 0xE4
        SFSP Version: v2.5.0
        Debug in Low Power mode enabled
        
        Opening and parsing file: target.hex
        
        
        Memory Programming ...
          File          : target.hex
          Size          : 4.90 MB 
          Address       : 0x08000000 
        
        
        Erasing memory corresponding to segment 0:
        Erasing internal memory sectors [0 34]
        Erasing memory corresponding to segment 1:
        Erasing external memory sectors [0 1185]
        Download in Progress:
        ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±± 0%
        Û  2%Û  4%Û  6%Û  8%Û 10%Û 12%Û 14%Û 16%Û 18%Û 20%Û 22%Û 24%Û 26%Û 28%Û 30%Û 32%Û 34%Û 36%Û 38%Û 40%Û 42%Û 44%Û 46%Û 48%Û 50%Û 52%Û 54%Û 56%Û 58%Û 60%Û 62%Û 64%Û 66%Û 68%Û 70%Û 72%Û 74%Û 76%Û 78%Û 80%Û 82%Û 84%Û 86%Û 88%Û 90%Û 92%Û 94%Û 96%Û 98%Û 100%
        
        File download complete
        Time elapsed during download operation: 00:01:18.537
        
        Hard reset is performed
        Done
    Done

5) Unfortunately, we are unable to see the output on the LCD itself, it is just blank :(


Would you have any thoughts/suggestions or be able to point out where I may have gone wrong or have not considered certain things? Would really appreciate it :)

Thanks again!

[mathiasmarkussen · Accepted solution]

Hello,

I have looked at the datasheet for the display controller on the display module (ILI9488). The interface type is selected via a set of pins, and as far as I can tell these are not routed to the connectors on the board. I assume that in this case, they are set to 16-bit mode, so it would not be enough to just connect 8 pins.

In case the backlight does not even come on, you can try to reverse the polarity of the PWM pin.

Just for reference, the V1 has never been supported directly by TouchGFX, but Riverdi may be able to help with some of these questions. They may have a solution for you, either by hardware or software means.

If you want to get your V1 working, you should connect all the data pins, define the actual pins used to some that are available in the connector on the Nucleo board and set up the FMC to run 16-bit mode. This should be fairly straight forward in CubeMX, but it is a lot of wires.

I will also reiterate that it is much simpler to debug this if you make sure to keep assets in internal flash until the screen works.

Then, when the screen works, try external flash, and if you have problems with that, ensure that the data you expect is actually available in the flash and also read properly by the MCU.

In the end, you will probably be a lot better off if your second module ends up being a V1.1.