Cypress Flash Programming using Nios II - Not working

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
symo_4766846
Level 1
Level 1

Hi

We had a legacy design using the Cyclone IV FPGA - EP4CE22F17C8N connected to Flash - EPCS64N. Since the EPCS64N was obsolete we replaced it with Cypress Flash - S25FL064LABNFI040. We are then trying to program the flash using the AN98558 app note - https://www.cypress.com/file/202476/download. While we are able to program the .sof file we are not able to program the flash. We are using the "Quartus II Web Edition Design Software, Version 13.1" and QSYS for target platform design and compilation. Latest 13.1 updates have been installed. Also using "Nios II 13.1 Command Shell" to program the .sof and flash. But we are getting - "there are no nios2 processor available that match the values specified" error. The schematic interface between FPGA & Cypress Flash, Qsys design, Assignment editor configuration, flash override file and command shell error pics are attached.

We would greatly appreciate it some one here can suggest a way ahead.

Syam - Degree Controls (www.degreec.com)

0 Likes
21 Replies
YongQ_16
Employee
Employee
10 sign-ins First solution authored 10 replies posted

Hello,

The Qsys design shows the epcs_control_port is at base 0x0800 but the command line is using 0x120000 as the base. These two numbers must be matching; otherwise the nios2 programmer will not be able to find the core.

Please fix this and try again.

Thanks,

Yong

0 Likes
lock attach
Attachments are accessible only for community members.

That pic got added accidentally. The base address is set correctly as in the attached pic. But got the same error as noted earlier. Then I changed the base address explicitly inside the Nios2 Processor also yesterday (attached). Since then am getting a message in the programmer command line tool where the tool is searching for the flash but unable to find it (attached). Please help.

0 Likes

Hello Syam,

Is it possible to hook up a scope or logic analyzer on the SPI bus to watch the signals when NIOS tool commands are entered. If the commands don’t show up correctly on the SPI bus, then something is wrong with the Qsys design.

The method in AN98558 you are referring is a workaround when all other methods failed. Can you please try Quartus programming tool to program the flash as if it is an EPCS flash? Make sure to disable EPCS ID check when create the .jic file.

Btw, from the attached schematic, I see the flash CS# signal is directly connected to the controller without a pull-up resistor. Is CS# signal guaranteed to stay high during Vcc ramping up? If CS# comes low during Vcc ramping up, it violates flash Power On timing requirements and may cause flash malfunction. Is it possible to add a pull-up resistor on CS# signal?

Thanks,

Yong

0 Likes
lock attach
Attachments are accessible only for community members.

Thanks Yong for your prompt response thus far.

We tried programming with .jlc file (EPCS ID check disabled) earlier. But it failed (pics attached). So we are trying to implement the workaround.

Currently the boards are being shipped from our US office to India office. So we can add the pull up to CS line and hook up the Oscilloscope a week later or so from now. Meanwhile I can share the oscilloscope pic we took sometime ago (pic attached). The green signal is CS and the yellow signal is clock. At that time we were getting the processor reset error and were testing in 13.0 of Quartus (pic attached). Since then we moved to 13.1 since we read that 13.0  has a bug that cause this error. Now we are testing with 13.1 only.

Also now we have kept the PCB with the FPGA and flash ON continously. Since we are trying to program in that continously ON mode, does the flash "Power On timing requirements" come in to play here ?

0 Likes

Hello Syam,

Thanks for the update!

From jic-1.png, seems like the operation failed because "Can't recognize silicon ID for device 1". Was device ID check actually disabled?

Regard to "Power On timing requirements", incorrect Power On timing may cause flash device not initialized correctly. The impact is not only for the period of power up. It remains until the flash device re-power on with correct Power On timing.

I do not see the oscilloscope pic you mentioned. Was it missed?

Thanks!

Yong

0 Likes
lock attach
Attachments are accessible only for community members.

Thanks Yong. The oscilloscope pic captured earlier is attached. The device ID check was disabled when we converted the .flash file to .jlc file. Tried a couple of times. Not sure why the error message is coming like that.

The boards are not yet here. We hope to pull up the CS line and probe with the oscilloscope as soon as it is here.

Do you see any problem with the target map in QSys...? Do you see any problem with the NIOS2 configuration ? Both pics attached once more. Is there anything that needs to be changed or tried differently ?

Best Regards

Syam

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Syam,

The oscilloscope waveform does not seem to be correct. The CS# signal must be driven high exactly at the multiple of eight clock cycles boundary. Otherwise, the command is rejected and not executed. In your oscilloscope waveform, the CS# is driven high at the 9th clock cycle of the 2nd group of clocks. Please see the attached oscilloscope waveform with my marks.

As to "The device ID check was disabled when we converted the .flash file to .jlc file. Tried a couple of times. Not sure why the error message is coming like that.", was this tested with Quartus Programmer following AN200498? If yes, can you please try Quartus II version 14.0 or later version. As stated in the AN200498, older version of Quartus II does not work for the procedure described in the document. 14.0 or later version is required.

As to configuration following AN98558, I see you have attached 3 test logs (different errors). Is the one I attached with my this response the latest one? I see in the log, it looks for EPCS registers starting from address 0x0000000A, even you have -base=0x120000 in the command line (see the attached screenshot with my marks). In the AN98558, the log shows "Looking for EPCS registers at address 0x00120000" which is the same as the -base in the command line (see section 3.3 on page 6 in the document). The command you input in the command line "nios2-flash-programmer --epcs –base 0x120000 --debug" is the same as the one for Quartus Prime 17.0 in AN98558. Can you please try "nios2-flash-programmer --epcs --base_address=0x120000 --debug", as I see you are testing with Quartus 13.1?

Can you please try re-run the test from the beginning following AN98558. Please follow the instructions for Quartus 13.0.

When create the Override File for Nios II (section 3.2), use the following information for S25FL064L which you are testing with.

[EPCS-016017] # Cypress SPI Flash S25FL064L
sector_size = 65536
sector_count = 64

Best Regards,

Yong

0 Likes
lock attach
Attachments are accessible only for community members.

Thanks Yong. I will send an oscilloscope signal later once we capture it.

AN200498 is for CYCLONE V. We are using CYCLONE IVE - EP4CE22F17C8N. Is the said app note applicable to this FPGA ?

Am attaching new logs from Quartus 13.1 all done from scratch.

"nios2-flash-programmer --epcs --base_address=0x120000 --debug" command doesn't work as you can see in the "Nios2 - Command Error.JPG". What works in Quartus 13.1 CLI is "nios2-flash-programmer --epcs --base=0x120000 --debug"'

What should be the voltage level? I tried both 2.5V and 3.3LVCMOS. Both were giving the same result.

Please get back to me if you see any obvious errors in the attached pics.

Best Regards

Syam

0 Likes

Hi Syam,

I don't see any obvious errors in the attached logs.

The flash(S25FL064L) you are testing is 3V device. Its working voltage range is 2.7V to 3.6V. 

Did you create the Override File as below?

[EPCS-016017] # Cypress SPI Flash S25FL064L

sector_size = 65536

sector_count = 64

Is the incorrect timing (i.e., CS# signal is raising at the 9th clock cycle) fixed?

Are you able to use a Logic Analyzer with QSPI protocol to capture the trace of the first flash probing command?

Thanks!

Yong

0 Likes

Hi Yong

I owe you the scope pics. We will send it. Our oscilloscope is out for maintenance. Because of the COVID situation here it is getting delayed.

The override file is correct. We modified it as per your advice.

Does the target design work with internal clock or external clock ? We don't have any external oscillator connected to the FPGA.

Best Regards

Syam

0 Likes

Thanks Syam!

I believe the target design is using internal clock. From the scope picture, the clock signal seems to be fine. The problem is that the CS# signal is not driven high exactly at the multiple of eight clock cycles boundary as we discussed earlier.

After you fixing this CS# raising issue, if it still does not work, I'd like to also see the Logic Analyzer trace of the first flash probing command (i.e., read device id), to see if the correct command is sent to flash and if the flash responses correctly.

Thanks!

Yong

0 Likes
lock attach
Attachments are accessible only for community members.

Thanks Yong.

We have pulled up the CS line with a 1K resistor and the CS and DCLK line signals are attached. It's same as before. I am wondering since the target design is generating the clock isn't there an issue in the design ? I have done the design exactly like in the app note and things look fine there. Could there be a bug in the generated files that were not identified before?

Also, I have a question regarding the override file values. From what sections of the datasheet of S25FL064LABNFI040 do we figure out the sector_size and sector_count values we give in the file ?

Best Regards

Syam

0 Likes

Hello Syam,

The pull up on CS and the CS vs. CLK (raising after 9th clock) are two different issues. Both issues need to be fixed.

The purpose of adding pull up on CS line is to make sure the flash Power On Reset timing is satisfied so that the flash can be initialized properly during power up. Incorrect Power On Reset timing could cause the flash malfunction.

Both CS and CLK signals are input signals for flash. They are sent/controlled by SPI flash controller. This need to be corrected on controller. Adding pull up on CS line will not fix this issue. I am not sure why this happens. You may need to check the SPI controller. As this (CS raising at multiple 8 clock cycles) is the requirement from SPI protocol. I believe other vendor's SPI flash devices have the same requirement. The steps in the app note do not have any configuration for this.

The sector size in the datasheet is described in section 6.2:

"The main Flash array is divided into uniform erase units called physical Blocks (64 KB)". The sector count is the half of the total count.

Best Regards,

Yong

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Yong

We have the CS pulled up. So now that issue is solved.

The issue with the incorrect number of clock cycles am not sure what can be done. Since this is coming out of the target design recommended by CYPRESS, can anyone in CYPRESS please take a look and help us with this ?

Also, since the processor is scanning for the flash as in the attached pic doesn't it mean that it is recognizing the commands correctly ?

Best Regards

Syam

0 Likes

Hello Syam,

I talked with our Application Engineer who did the verification and wrote the app note. The verification and app note is done based on Intel/Altera SPI Controller IP. The app note describes the configurations required for Cypress flash. Nothing related to the CS vs. clock cycles issue. This issue might come from SPI Controller IP. However, we don't have the access to the Intel/Altera SPI Controller IP and not able to debug. You may have to contact Intel to help on this issue. Not only Cypress flash but also other vendor's SPI flash won't work with this timing (i.e., CS not raising at multiple of 8 clock cycles).

The attached log doesn't mean that it is recognizing the commands correctly. It just shows the error message that flash is not found. This is expected result as the flash won't respond at all due to the incorrect timing.

One clarification for my earlier response about Override File sector_count = 64, the total sector count for S25FL064L is 128. But this won't cause any issue. When sector count=64, only half of the flash space will be used. To use the full flash space, set sector count to 128.

Best Regards,

Yong

0 Likes

Thanks Yong. The application note says the solution described in it worked with Quartus 13.1. So if there was a problem with the SPI Controller IP of this version shouldn't it have appeared then ? Also is it possible to try implementing the app note design at your end and see whether it works as it says ?

We will contact INTEL anyway.

Best Regards

Syam

0 Likes

Hello Syam,

Because CS and Clock signals are controlled by SPI controller, we guess it might come from SPI Controller IP. However, without accessing to the Intel/Altera SPI Controller IP,  it is difficult for us to know what the exact reason and reproduce the issue. You may show the scope pic (CS vs. clock) to Intel.

After this timing issue fixed, please let me know if the flash can be recognized.

Thanks!

Yong

0 Likes

Hi Yong

While INTEL looks in to the issue we would like to look at the possibility of directly program the flash with out going through the FPGA. Can you please suggest a programmer for direct flash memory programming of S25FL064L ?

Best Regards

Syam

0 Likes

Hi Syam,

Many programmer vendors support S25FL-L flash family. Please check below link for the full list of the programmer vendors.

https://www.cypress.com/products/device-programmer-system-partners

On the page, click "Flash Memories" tab. You will see a table. The 1st column lists the programmer vendors name which has the links to their websites. Look at the middle column with header "S25FL-L". The cell marks "Y" means that vendor supports S25FL-L. You may check with the vendors on the detail (e.g., which model supports S25FL-L).

Best Regards,

Yong

0 Likes
lock attach
Attachments are accessible only for community members.

Thanks Yong.

Can you please check the attached images. I have marked a difference in the target design we created and that is there in the doc from cypress (AN98558). Any problem with our target design. No reply from Intel yet. Can you guys please check with Intel ?

Best Regards

Syam

0 Likes

Hello Syam,

Both images are correct. The cypress-design.png is the same as the Quartus 13.1 spi example (figure 2 in AN98558). Your design (degree-design.png) is the same as Quartus Prime 17.0 example (figure 3 in AN98558).

AN98558 first revision was created based on Quartus 13.1. It was updated to include procedural changes with Quartus Prime 17.0 after Quartus Prime 17.0 was available. Can you please check the AN98558 revision you are referring? The latest version of AN98558 is revision C.

Regard to Intel support, normally they are more responsive to their customers (e.g., your company). I don't think they will respond to my support request for this specific issue as we are not their customer. I will try to find out if our Intel interface will be able to help pushing them. But I am not optimistic.

Best Regards,

Yong

0 Likes