QSPI external loader issue

[Buelent Cakir]

Posted on November 02, 2017 at 10:29

Hi,

I'm using a S25F064F Flash on a custom STM32F446RC Board. Due the 64Pin Version of this Controller the Flash are connected as QSPI-DUAL (means only two data lines).

My issue with the attached Code is, that I can Programm only one Page even I get the error

10:06:41 : The elf loader Program function fails.

10:06:41 : Memory-Loader error

10:06:41 : Error occured during program operation!

10:06:41 : Programming error @ 0x90000003!

Afterward I see only one Page (256Bytes) programmed.

Similiar issue with the erasing of sectors. Only the first Sector are erased.

I can't see what is Happening in the Background and what is the ST-Link Util doing.

Maybe someone could have look in the Code and could found an issue.

Many Thanks in advance.

#qspi-flash #st-link-external-loader

[Buelent Cakir]

Posted on November 06, 2017 at 11:06

Ok, the last Letter is 'L'. That means, that the Flash has QSPI capabilities.

Thanks

[AVI-crak]

Posted on November 06, 2017 at 18:58

The S25FL064L chip has a fascinating user identification algorithm (page 53). This algorithm begins with the power supply, or software restart. Protection is designed to store content in secret, and has three levels:

1) no password no protection.2) there is a password, there is protection for all space or separate sectors without write protection.3) there is a password, the protection is removed by reading the first correct address (not zero).This algorithm must be passed in spi mode, after register access registers are available (their main number is 25). I have to admit - this chip can save the business, the program code will remain a secret.Then routine actions are performed.Adjust the power regulator.Configuring data bus latencies.Setting the command word mode (do not touch).Setting the data bus mode.Switch mode to flash.Switching the spi mode to QSPI on st.Test read / write.

A cursory examination of LOADER_SRC_H program code - gives some mismatches of command words with documentation.

[Tesla DeLorean]

Posted on November 06, 2017 at 19:06

Before coding the loader have a demonstrable and validated test framework for the chip working from application space.

[AVI-crak]

Posted on November 06, 2017 at 19:32

Clive One

I'm used to looking at functions that can be completely displayed on the screen without scrolling down and additional viewing of 14 separate files. It is difficult to look for an error.Buelent CakirBut better late than never: whose code is this? whose prototyping board? where did the S25FL064L come from? how is an attempt to program it?

[Buelent Cakir]

Posted on November 07, 2017 at 02:00

Hi, I add already the whole Project Folder as one zip file.

To your questions:

The Code are sticked togehter from the available ST examples and adjusted based on the cips. The Board is a custom board. The Flash are coming from Farnell.

On the same board I had the N25Q064 from Micron and it was possible to program and read data within the application.

My Issue are with the external loader. I don't see any proper documentation. Today I called ST to get Support, but they forwarded me to the Distributor from where I bought the uC, but they can't Support me.

[AVI-crak]

Posted on November 07, 2017 at 09:33

Interesting details ...

N25Q064 differs significantly from S25FL064L in the recording algorithm - other registers, the bits for the checks have a different place and name. Long waiting for the recording of the first data block is the result of incorrect polling of the status flag. I have already mentioned the discrepancy between the bit names and their contents.ST-Link Util does not use a direct reference to the periphery of the μ when recording an external flash, instead it uses ring buffers in memory μ, and known function names. I'm not sure about using function names, but it seems to me to be more real. Otherwise, ST-Link must use the function addresses known to it - this is easier for the first step, and a huge problem for the development of the project. Fixed addresses are always a problem.

That is, the names of functions and their list of arguments can not be changed, but the contents of functions can be changed. This means that the function can be checked for autonomy, as part of the test firmware - in debug mode.