STM32F7 External Flash loader using QuadSPI

[Fahad Siddiqui]

Posted on February 02, 2018 at 07:30

Hi,  I am developing a GUI based project using Waveshare Open7xxi board. The board consists of a stm32f746 controller. Since this is a GUI project I am saving all the graphic content in external Quadspi flash. Previously I have used STM32f746 discovery board, which has micron quadspi flash. To load the code into quadspi at the time of flashing the code, ST has provided driver(.stldr) file.   

Since I'm using W25Q128 qspi flash, I don't have external driver file for that. I have tried creating the (Flash load algorithm)FLM file using Keil, but when I saw it at logic analyzer, I wasn't able to see the clock.   

Since there is no source code available for STM32F7 external quadspi flash, I'm facing a hard time to write the flash load algorithm. Can anyone tell me what should I do to approach this problem? Does anyone have the source code for STM32F7 external flash which is using Quadspi?  

#stm32f746-qspi #stm32f7 #st-link-external-loader #stm32f7qspi #stm32f746-discovery

[Francesco CARIATI]

Posted on February 02, 2018 at 07:44

Hi

Siddiqui.Fahad

‌

I've moved your thread from the 'About this community' space (which deals with issues regarding the community itself) to the appropriate STM32 forum where you'll find the help you need

[Gln]

Posted on February 02, 2018 at 08:52

Hi

Siddiqui.Fahad

‌,

The ST-Link User Manual (

http://www.st.com/resource/en/user_manual/cd00262pdf

), Section 3.9

Developing customized loaders for external memory might be helpful.

I do not have the source code for the STM32F7 discovery board but since it is using the Micron N25Q128A Flash memory, I would assume that the code would be similar (but different!) to the ExternalLoader example for the STM32L476G_EVAL board using the N25Q256A FLash memory:

C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility\ExternalLoader\N25Q256A_STM32L476G-EVAL_Cube\Projects\STM32L476G_EVAL\Examples\QSPI\N25Q256A_STM32L476G-EVAL

Are you facing any particular issue?

Regards,

Guillaume

[Fahad Siddiqui]

Posted on February 02, 2018 at 10:46

Hi

Legrain.Guillaum.002

,

Thanks for the quick reply.

I already tried that STM32L4 external loader code for

N25Q256A FLash memory. Since Quadspiregister for stm32l4 and stm32f7 are same, I could use that file. But I'm facing problem in RCCconfiguration.

I am trying to write the Flash Load Algorithm that I could use with Keil5.

I don't actually know, how to configure RCC at boot-time. I have a working driver for W25q128 with quadspi, which I created from Cubemx, But when I try to use it for the external loader algorithm, Flash is getting reset timeout.

I have used the same RCC, GPIO and Quadspi configuration as I have used in my working driver for w25q

Can you tell me what I need to configure at Init?

I am attaching the source code which I have made using stm32f7 hal libraries. It creates an FLM file that I can copy to arm/flash folder of keilv5. I am able to see my algorithm, but it's telling me flash reset timeout.

https://drive.google.com/file/d/1fS4yxfyPWTnLyneSjSkqFREj64l5_BtX/view?usp=sharing

[hans23]

Posted on February 02, 2018 at 22:17

Hi,

please take a look at  STM32F746-CubeMx Firmware under Drivers/BSP. Here you can find the QSPI Drivers for the STM32F746DISCO.

beste egards

Werner

[Gln]

Posted on February 04, 2018 at 08:09

Siddiqui.Fahad

‌,In your project it looks like you are using the Init function fromFlashPrg.c but I don't see any RCC configuration (i.e.SystemClock_Config(); call) as it is done in the Init function of Src\Loader_Src.c. Is this intended?

You could probably copy the RCC configuration from your working project that you created with CubeMX into you project by copy pasting the

SystemClock_Config() implementation CubeMX generated for you.

Regards,

Guillaume

[AVI-crak]

Posted on February 04, 2018 at 09:14

Making the firmware for external memory is an insanely long process. My machine works almost an hour, assembling the firmware in one pass for 512MB memory. It is very long in manufacturing, but very quickly in access. I do not use a file system. Instead, a static structure is used. The structure branches at filling have external connection of the cropped file of format C. It looks something like this:

#define graphics_package 0

QUADSPIRAM static struct

{

     uint16_t image01 [0x25800];

     uint16_t image02 [0x25800];

.....

grafik

#if (graphics_package == 1U)

 = {

    #include 'image01.h'

    #include 'image02.h'

-------------

The collected elf has a giant size, it makes a separate * .bin for external memory, using the section name as a parameter.

arm-none-eabi-objcopy -O binary -j. (partition name) (filename) .elf (external memory firmware name) .bin

Then the magic begins.

If you need one-time programming, it's better to use an external programmer - literally. The recording speed will depend only on it. For example, the popular CH341 programmer spends half an hour writing w25q128. More expensive ones can be recorded in ten minutes. And you will need equipment for soldering.

If you are a fan of the BDSM subculture, you can pour the external firmware through the bottleneck of the SW interface. This is an insanely long process, in my case more than five hours. Maybe I did something wrong, but I have no desire to understand.

The third option is to create the firmware of an external programmer using CubeMX. It's like big brothers. Full initialization of all required peripherals, including usb and fatfs. A bit of magic, and a usb connection will make it possible to record external memory at maximum speed, about seven minutes.

[Roland Hoesch]

Posted on February 20, 2018 at 18:00

Hi,

can you give some hints about the magic of your third option? Is the source code of this 'magic' available?

[AVI-crak]

Posted on February 21, 2018 at 00:55

It does not make sense, I have to rewrite the driver for a new type of external flash memory each time.

The algorithm itself is very simple, it is described in the documentation for external memory.

1) enable recording, wait for the recording status.

2) clear the sector, wait for the status of the flags.

3) write down the block, wait for the status of the flags

4) repeat step three until the sector is completely recorded

5) remove the recording mode.

Some chips themselves reset the recording mode after one operation, and this is described in the documentation.

Tip - the block size (almost always) is the same as the size of the write cache of the qspi peripheral. It is enough to set the buffer full wait bit, and to write to the buffer without observing ideal timings. In the case of direct block writing, it is nonlinear - there will be an error record. During the block recording, you can not remove the CS signal, as well as the clock signal - this piece of data should be sent as a single unit.

[Fahad Siddiqui]

They have now included source code for quad spi loader for stm32f7 devices. C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility\ExternalLoader\N25Q512A_STM32F769I-EVAL

People who are still struggling with the driver of quadspi external loader, can find it here and rewrite their own driver.

[yldzmuhammed]

Did you solved yours? How did you? I can not use that file you pointed out?

[lexabps]

http://www.firebbs.cn/thread-27799-1-1.html

[lexabps]

http://www.firebbs.cn/thread-27799-1-1.html

[lexabps]

interesting project

[Tesla DeLorean]

So is this your board, or someone else's? Available anywhere?

QSPI(BK1)

CLK:PB2:AF9

D0:PD11:AF9

D1:PD12:AF9

D2:PE2:AF9

D3:PD13:AF9

NCS:PB6:AF10

SDIO/SDMMC2

CLK:PC1:AF9

CMD:PD7:AF11

D0:PB14:AF9

D1:PB15:AF9

D2:PB3:AF9

D3:PB4:AF9

CARDDET:PE10

[lexabps]

Thanks to all. The problem is resolved. The chip is defective.