Can't program for STM32F746G-DISCO using STM32-ST-Link-Ultility

[HAnh]

Hi Everyone.

I have problem with  STM32F746G-DISCO when i program .hex file demo as link https://www.touchgfx.com/resources/demos/

i'm doing step by step follow in pdf file attached in demo folder.

When i load .hex file in folder "3DBoxDemo" it is OK and run normal.

When i load .hex file in folder "touchgfx_demo2014" it show me a message as "TimeOut" picture. But when i restart STM32F746G-Disco, i see that have program running, but background color is red.

This happen again when i load .hex file in folder "touchgfx_demo2015_480x272_8MB", that mean i see that have program running, but background color is red.

I'm afraid that QSPI chip on STM32F746G-Disco have problem, so that it can't load background.

i hope anyone can help me solve this problem.

Thanks And Best Regards.

[Tesla DeLorean]

Try using the STM32 Cube Programmer application with the appropriate External Loader

Might also recommend trying the command line version of the ST-LINK Utilities.

Current firmwares and versions of all tools.

[HAnh]

Hi clive1.

Thanks you for your advice.

But i don't know clearly your advice.

Could you tell me more detail "command line version of the ST-LINK Utilities"?

About current firmware and versions of all tools, i have already used latest version. It's Ok When i load .hex file in folder "3DBoxDemo".

[Ozone]

> I'm afraid that QSPI chip on STM32F746G-Disco have problem, so that it can't load background.

I suppose your toolchain or programmer (ST-Link utility) can't deal with the external Flash at all.

[HAnh]

ST-Link utility support external Flash, so i have selected external flashloader for F746g-disco in the External Flashloader settings.

I don't know, What is happening for my kit?

[HAnh]

I have already replace QSPI chip on STM32F746-Disco, so could anyone can help me, how to program QSPI on on STM32F746-Disco?

[Andreas Bolsch]

First: Try to mass erase internal and external flash with the ST-Link utility, then disconnect and reconnect power to the disco board to make sure a power-on reset occurs. Then try to program the stock firmware shipped with CubeMX:

STM32Cube_FW_F7_V1.15.0/Projects/STM32746G-Discovery/Demonstrations/STemWin/Binary/STM32746G-DISCO_Demo_V1.5.0.hex

This way it's possible to find out whether the problem is the actual flash programming or in the firmware you intend to program.

Second: When does the "Timeout" appear? During the flash programming? If so, I'd suspect the option bytes, in particular the WWDG_SW and IWDG_SW. If any of them is cleared, the corresponding watchdog might kick in during programming of the external flash. I remember my disco board came with one of them cleared ... Don't know whether they're still shipped like that.

Third: After (unsuccessful) programming of the demos you tested, the part of the firmware in internal flash certainly configures the external flash for memory mapped read. So, you should be able to inspect memory at 0x90000000 onwards with (almost) any debugger via plain memory reads. At least partially programmed or still all 0xFFs?

[HAnh]

Hi Andreas Bolsch

Fist: I have already erase internal success, but erase external flash that's failure (i have replaced QSPI chip on STM32F746-Disco )

Second: About option byte WWDG_SW and IWDG_SW they are checked.

Third: I'm using STM32 Programmer and  inspecting memory at 0x90000000.. so all data is 99999999.

So i'm don't know anything about how to QSPI operation?

do i must program any loader to QSPI before i'm program to STM32F746-Disco?

[Tesla DeLorean]

Replaced it with what? Exactly the same part number?

You're probably going to want to validate the QSPI read, write and erase from the application side. Check the QSPI and BSP examples provided in the CubeF7 package.

[HAnh]

Hi clive1 (NFA Crew)

I have Replaced it with exactly the same part number on STM32F746-Disco.

beside that i have Checked the QSPI and BSP examples provided in the CubeF7 package, so it's not success full with issue "can't erase external flash"

When i have new QSPI, do you think i need program loader for new QSPI chip before using it?

Do you think my STM32F746-disco have problem with QSPI interface?

[Andreas Bolsch]

Replacing the chip with another one even with same part number might *NOT* be sufficient. The N25Q128 has a number of non-volatile settings, which might have been changed from factory default values during board manufacturing. In particular, number of dummy cycles, enabling DPI and QPI mode, drive strength. All these can be overridden at run time of the firmware and of the flash loader but maybe both rely on the values set during production and don't bother with reconfiguring to suit their needs. Clive is right, the 99999999 sounds much like QSPI interface and flash chip not having the same setting regarding QPI mode. I'm afraid diagnosing this problem is getting to be complicated. Even with an interactive tool you will have to know precisely what's happening on the "wire" and a thorough knowledge of details of the flash's registers ...

[HAnh]

That mean QSPI chip have configure before assembly on STM32F746 disco. So how we can read configure from QSPI from there and program for the new QSPI.

Because I have a customer board Using STM32F746 and QSPI​ LIKE STM32F746-DISCO. That is reason why i replace OLD QSPI by new QSPI.

I have tested them in my board. So it have problem as I describe in this topic.

So how can I solve this problem?​

[HAnh]

Hi clive1 (NFA Crew)

i have already replaced the old QSPI and this run normally.

So why when i replaced the new QSPI that problem happen.

that mean STM32F746-disco don't have problem with QSPI, i think problem this is a new QSPI.

so if i make a customer board using STM32F746 and QSPI, how can i program new QSPI?

[Tesla DeLorean]

There are lots of reasons why things don't work or fail. A chain is no good if any of the links are broken.

I've personally not had issues with the QSPI devices on the F746G-DISCO board, and I've rebuilt drivers and loaders for them.

The STM32 Cube Programmer is the tool most currently developed by ST to program the boards, the ST-LINK Utilities being the more deprecated tool. They also have command line variants, which I believe are documented and will output a usage or man-page type output describing parameters, etc.

Large QSPI devices can take a very long time to erase, NOR Flash is not particularly fast on the write/erase side, it is optimized for read.

When working with QSPI devices on STM32 parts I have generally written my own test/stress applications to evaluate performance, and circuit functionality, so I can apply this to new designs for boards I have to work on.

The application will usually use the JEDEC ID function to identify the part, and correlate that with the production documentation, and command list. Different makes, model, and versions usually have subtle differences.

[HAnh]

I think you right.

So do you have any experience about my problem I have.

I want to know. What need I do with new QSPI chip to make it run normal in my customer board

[Andreas Bolsch]

I've just checked on my Disco board: The non-volatile configuration register of n25q128 is still at factory default. If the replacement flash chip you've mounted is not a special pre-configured version or a used one, it seems that your hardware is broken.

The pads of the flash chip are easily accessible with a scope's probe, so you might check whether all 6 signal pads show reasonable signals. If yes, the flash chip is the culprit (or its solder joints), if no ... then the board is broken.