Nucleo-H563ZI with RVA35HI - TouchGFX demo project not flashing correctly?

[brandonfox]

Hello. I am very very new to the world of STM32 microcontrollers and products. I've recently purchased the Nucleo-H563ZI board with RVA35HI Rev 1.1 display. I am starting slow, so to begin I tried utilizing the demo project in TouchGFX called "TouchGFX Demo 1 Alternate". After some troubleshooting, I've successfully flashed the demo project to my development board. The screen lights up white upon upload and I don't see the start up screen. Messing with it I discovered the project is uploaded, and still responding to touch because there is one screen that shows graphs, which for some reasons shows up. I've left the board in its default configuration as far as jumpers are concerned. I believe I have all required software downloaded. I've followed the instructions of some guides online and don't understand what I'm doing wrong.

Thank you.

See attached: Pictures of board lighting up, showing graph, and the simulator screen with the graphs.

[brandonfox]

It seems like I'm still running into the same problem.

Just for the hell of it I tried changing my programmer to "hardware reset" and that didnt change anything. Then I made a new project in TouchGFX to confirm the upload is working by changing the screen to a solid color (doesn't need to save to external memory) and that worked...

[Osman SOYKURT]

Hello @brandonfox ,

Ok, we're progressing :)
Last thing you could try is to write on ext memory using STM32CubeProgrammer directly (just try to put random value in memory range of 0x90000000) Remember to use correct ext loader.

If that doesn't work either, I would advise to contact Riverdi (and maybe ask them to change your screen).

[PSTuser]

Writing to the flash locations didn't work. There is activity on the IO but the data is not taken.

As far as I understand the flash became write protected at some point.

Also if the flash is used in memory-mapped mode then only read operation is allowed.

There are posts that try to go into the status registers and clear bits but we are not familiar enough to do that.

Are there any project out there that can clear the write protect?

[Tesla DeLorean]

I've built loaders that can back out Winbond BPB/COM settings, and pull high D2/#WP

W25Q64 being the prime problematic device that's come across my desk.

What's the pin allocation usage here? I'll rustle up a loader / port to H5

https://github.com/cturvey/stm32extldr/tree/main/h7_w25q64

Edit:

STM32H563ZI / W25Q64

PB2:AF9 CLK

PG6:AF10 NCS

PD11:AF9 D0

PD12:AF9 D1

PE2:AF9 D2

PD13:AF9 D3

[PSTuser]

I replaced the winbond flash with N25Q064 we had in house and it worked.

At least I hope it's not temporary fix.

We will keep your loader on hand if this comes up again.

How do we use your loader if this comes up again?

Where and how do we use it to clear the write protect?

We will continue playing with TouhGFX for now.

Thank you all!

[Tesla DeLorean]

For the H563ZI w/RIVERDI REV 1.1 pin usage

https://github.com/cturvey/stm32extldr/blob/main/h5_w25q64/CLIVEONE-W25Q64_STM32H563-PB2-PG6-PD11-PD12-PE2-PD13.stldr

>>Where and how do we use it to clear the write protect?

As part of the Init() mechanics I read the JEDEC ID and SR1/SR2, there I make sure the BPB/COM bits are default, ie not protecting. I also bring up the D2/#WP(IO2) pin with a pull-up, so that during initial usage in 1/2-pin mode, before transitioning to 4-pin mode (not quite same as QPI, but rather the expectations that D2/D3 aren't #WP/HOLD). If D2/#WP seems low the chip will see this as a hardware write protect.

The Winbond W25Q64 has gone thru multiple die revisions, and can have factory settings as to being a legacy 2-pin or not. Part# has a millions suffixes

Some of the Winbond / Macronix / Micron have different methods to QE, the one from Macronix would often lock Micron by setting a BPB bit (0x40), so mass erase and some block writes would fail / complete immediately.