Use of arbitrary DataFlash of the 25th series instead of expensive Altera FPGA configurators without additional hardware
From any description on popular FPGA it is known that special configuration chips are used to store their configurations. In the comments, I was corrected that FPGAs are slowly gaining popularity, where it is not required, but so far many people are developing on the classics, where a configurator is needed, and this has to be considered. For example, for Altera Cyclone, EPCS chips are used. Below is a diagram of a typical Cyclone IV crystal board. On it we see the EPCS16 configurator. All anything, but traditionally these configurators are quite expensive, so I would like to use something cheaper.
Details in the long text below. If it is very interesting, but too lazy to read so many letters, then you can simplify the task by watching a detailed 20-minute video.
So back to our problem.
')
If we turn that very prototype board with a crystal of the Cyclone IV family in our hands, we will see a very amazing thing.
Here it is, PLISina, and here is the configuration ROM:
Oddly enough, this is not an EPCS, but an ordinary 25th flash drive. These flash drives are cheap and sold quite a lot from anyone.
But as they say, not all yogurts are equally beneficial. In particular, our customers happily bought similar flash drives, soldered to the board and got a global problem. Go to the programmer, load the file prepared for the firmware, start to flash it and get the error:
Here is the error message:
Error (209025): Can not recognize the silicon ID for the device. Verify that all cables are connected to the target system. Make sure the device pins are connected and configured correctly.
Device ID not recognized. That is, the flash drive has an unknown identifier from the point of view of the quarter. Specifically, 25P32 crystals were purchased from our customers, which are not supported at all in principle, but there may be a more mundane situation in life. In particular, in the photo above, the flash drive from ST is soldered, and it is defined as MICRON. Chinese sellers and not so can mark, and when the party is purchased and does not work - what can be done?
I got on the forums. All the Russian-speaking, which were able to inspect, were full of discussions from which suppliers and what should be taken so as not to run into a similar problem. But in our case, no one wanted to buy a new batch. In the English-speaking sources, only one article with the solution was found, but in the modern environment of Quartus Prime this solution “head-on” will not work. Therefore, we undertook to document this problem for the modern environment, in Russian and in video format.
So, how is PZUshina generally programmed?
A special configuration is poured into the FPGA, according to which it becomes possible to get a flash drive via JTAG. And then, using this configuration, we fill in the data. It turns out that you can make a similar configuration, which will give us access to the flash drive and allow us to flash, regardless of the ID, and you will not have to write a single line of your own code, and all utilities will be supplied from Quartus Prime (or Qiartus II, who use the old development environment versions).
That is, we have to do 3 steps:
Let's do this and do it. Let's start with the development of its own "firmware" (the same configuration), without writing a single line of its code.
Go to Quartus:
Create a new project:
Let's call it, say, flasher:
This name should be remembered - we still need it.
Create an empty project, I have a family of Cyclone IV E, the crystal used in the project is:
So. Finish the creation of the project, click Finish. Project created. As already mentioned, we do not write a single line of our code. But getting the environment to do something is still needed. To do this, go to Tools - Platform Designer.
Here it is loaded. Specifically, I have 60 Hz quartz in this board, so I will correct the frequency settings:
What I do now, we do once for the platform. That is, if some kind of board is made, then this bootloader will work for it for any project.
I prepared a quartz - now we put the processor. In the library on the left we find "Processors and Peripherals", "Embedded Processors" and then the Nios II Processor:
Select it and click "Add".
In the window that opens, in the properties, choose Nios II / e, because it is absolutely free and it does not need any license.
Errors tell us that vectors are not configured. We are not going to program anything for this processor. Therefore, we simply send the vectors to the first available place from the list:
It is very important for us that the processor has a JTAG module:
After our manipulations, the errors are gone.
With the processor finished. Click Finish and move on.
Now we go to the main functions. There are configurators here:
We open the list of configurators - closer to the end we find EPCS-ki - our configurators:
We leave everything by default:
Now we begin to bind them. The clock signals are passed to both modules, the reset signal is passed to both modules. The reset signal from the JTAG hardware, debug_reset_request, is also passed to both modules. Next, we skip the data_master to both modules. Instruction_master is skipped only to the debugger. And we also skip the interrupt request:
Then we go to the external legs - external. Export them by double-clicking in the Double-click to export field:
For simplicity, I’ll call epcs so that less length is:
Now, with the usual hand movement, we assign base addresses:
And assign interrupts:
The automatically assigned address for our flash controller is 0 × 800 — we should remember:
He is still useful to us. And everything else, in principle, itself has become and will work.
Now it is very important, since we are not going to write a single line of our code so that the name of the processor system coincides with the name of the project. The project we had was flasher.
Save the system, call flasher:
That's when we have the top module is this processor, and therefore we do not have to do anything.
Our next step:
We leave everything by default, because we simply use what is already ready:
We finish:
There was a message that we need to remember to add the file to the project:
Let's add. Go to Project - Add / Remove Files in Project:
We find our file on the computer.
Here it is, our flasher file with the qsys extension.
Added it:
Now we make a draft compilation:
It ended successfully.
Now that it has passed, we can assign conclusions. Go to Pin Planner:
We do not need to assign JTAG legs - we assign the legs of a flash drive.
For each chip, for each case, they are their own. In principle, you can watch the documentation on the chip or on your board. For example, here we have the twelfth leg of the DCLK:
My list has already been prepared - just sort it out.
Thus, epcs_data0, LOCATION: PIN13, epcs_dclk - PIN12, epcs_sce - PIN8, epcs_sdo - PIN6. And specifically on the board of our customers the clock frequency PIN24, reset_n - PIN88.
Legs appointed. We start compilation. Errors are issued:
All because I pretended that I forgot to make a very important setting. We have now connected the flash drive to the service lines. And, at the end of the configuration, some of these lines are not available at all, and some are used for service purposes. Therefore, we were given messages that we have a conflict:
To eliminate this, go to Assignments - Device:
Device and Pin Options:
Here we select Dual-Purpose Pins. And at the end of programming we ask all these lines to be made with ordinary I / O lines:
Click OK, run the compiler. And everything turned out.
So the first step is complete. We have a configuration through which we can reach the flash drive.
Now our task is to make a file with which the system will recognize our flash drive.
We go to all programs, Intel FPGA (for older versions it will be Altera), Nios II Command Shell.
Here we go to the directory where we have just collected everything. At the same time, we don’t forget that the slashes here should not be inverse, but direct, and that the resulting flasher.sof file lies in the output_files directory:
Now we begin to cast magic spells. So, we need to pour in the newly formed configuration. For this we write:
nios2-configure-sof flasher.sof
and press Enter:
The file is full - now we have access to the flash drive. In order to determine everything related to access to the flash drive, we need to run the following program:
nios2-flash-programmer --epcs --base = 0x800 - debug.
where 0x800 is the same address that was automatically assigned to the epcs block and which should not be forgotten.
Press Enter:
What did he tell us? He tried to explore the area that we called. And at offset 0 at address 800 did not find anything. At address c00, he found what we need:
Now we remember not just the base address 800, but the specific address c00 - in the future we will work with it.
He found a flash drive, its ID is 202016, but said that he has no idea what to do with it because he does not know it.
Here is the documentation for our flash drive:
Its full identifier is 202016 - that is what it returns in response to a command requesting its code.
So everything is correct - the flash drive was found correct.
He tells us that there should be a file with the section EPCS-202016.
Wonderful. Edit - Mark. Select its name and take it to the clipboard.
Create an ovr.txt file and a section with the name you just copied:
In the documentation for our flash drive, in the section Memory Map, we can see that it consists of 64 sectors. Each sector has a size of 64 KB, because from 0000 to FFFF.
Therefore, the configuration file we just created should look like this:
64 sectors of 64 KB in size, or 65536 bytes each.
The second step is ready. We have the files flasher.sof and ovr.txt, which contains the configuration of the flash drive.
Go to the third step.
Let me remind you that the working draft was USB16_my. And the firmware file was called Test1.sof. We copy flasher.sof and ovr.txt to it.
Now we have completed all the preparatory steps - proceed to direct hostilities. To emphasize the lack of connection between training and work, I will enter the terminal again, as if it happens the next day, a week later, a month later, or any time after the completion of the preparation.
The first thing we need to do is generate an output file. Because the sof file is not stitched in ROM - a slightly different file is stitched. In order to form it, we write:
The file Test1.flash turned out:
Now, purely formally, came the turn of the actions that the board builders should do. First of all, they should also load our flasher, that is:
After which they must flash the ROM:
Actually, that's all. The problem is solved, the flash drive is stitched - you can use it, even though the main way was talking about the mismatch of ID-Schnick. And you do not need to buy expensive configurators at all or look for the supplier from which the 25th flash drives have compatible IDs. We prepared a “flash driver” for our specific board (and any others where the same crystal and Reset with the generator are connected to the same output), we prepared a text file for the configurator, and then we poured the “firmware” using the utilities supplied deliveries of Quartus Prime standard environment (they also came with Quartus II environment).
Details in the long text below. If it is very interesting, but too lazy to read so many letters, then you can simplify the task by watching a detailed 20-minute video.
So back to our problem.
')
If we turn that very prototype board with a crystal of the Cyclone IV family in our hands, we will see a very amazing thing.
Here it is, PLISina, and here is the configuration ROM:
Oddly enough, this is not an EPCS, but an ordinary 25th flash drive. These flash drives are cheap and sold quite a lot from anyone.
But as they say, not all yogurts are equally beneficial. In particular, our customers happily bought similar flash drives, soldered to the board and got a global problem. Go to the programmer, load the file prepared for the firmware, start to flash it and get the error:
Here is the error message:
Error (209025): Can not recognize the silicon ID for the device. Verify that all cables are connected to the target system. Make sure the device pins are connected and configured correctly.
Device ID not recognized. That is, the flash drive has an unknown identifier from the point of view of the quarter. Specifically, 25P32 crystals were purchased from our customers, which are not supported at all in principle, but there may be a more mundane situation in life. In particular, in the photo above, the flash drive from ST is soldered, and it is defined as MICRON. Chinese sellers and not so can mark, and when the party is purchased and does not work - what can be done?
I got on the forums. All the Russian-speaking, which were able to inspect, were full of discussions from which suppliers and what should be taken so as not to run into a similar problem. But in our case, no one wanted to buy a new batch. In the English-speaking sources, only one article with the solution was found, but in the modern environment of Quartus Prime this solution “head-on” will not work. Therefore, we undertook to document this problem for the modern environment, in Russian and in video format.
So, how is PZUshina generally programmed?
A special configuration is poured into the FPGA, according to which it becomes possible to get a flash drive via JTAG. And then, using this configuration, we fill in the data. It turns out that you can make a similar configuration, which will give us access to the flash drive and allow us to flash, regardless of the ID, and you will not have to write a single line of your own code, and all utilities will be supplied from Quartus Prime (or Qiartus II, who use the old development environment versions).
That is, we have to do 3 steps:
- Make a configuration that gets to the flash drive.
- Write a file in which the flash drive is described.
- Flash
Let's do this and do it. Let's start with the development of its own "firmware" (the same configuration), without writing a single line of its code.
Go to Quartus:
Create a new project:
Let's call it, say, flasher:
This name should be remembered - we still need it.
Create an empty project, I have a family of Cyclone IV E, the crystal used in the project is:
So. Finish the creation of the project, click Finish. Project created. As already mentioned, we do not write a single line of our code. But getting the environment to do something is still needed. To do this, go to Tools - Platform Designer.
Here it is loaded. Specifically, I have 60 Hz quartz in this board, so I will correct the frequency settings:
What I do now, we do once for the platform. That is, if some kind of board is made, then this bootloader will work for it for any project.
I prepared a quartz - now we put the processor. In the library on the left we find "Processors and Peripherals", "Embedded Processors" and then the Nios II Processor:
Select it and click "Add".
In the window that opens, in the properties, choose Nios II / e, because it is absolutely free and it does not need any license.
Errors tell us that vectors are not configured. We are not going to program anything for this processor. Therefore, we simply send the vectors to the first available place from the list:
It is very important for us that the processor has a JTAG module:
After our manipulations, the errors are gone.
With the processor finished. Click Finish and move on.
Now we go to the main functions. There are configurators here:
We open the list of configurators - closer to the end we find EPCS-ki - our configurators:
We leave everything by default:
Now we begin to bind them. The clock signals are passed to both modules, the reset signal is passed to both modules. The reset signal from the JTAG hardware, debug_reset_request, is also passed to both modules. Next, we skip the data_master to both modules. Instruction_master is skipped only to the debugger. And we also skip the interrupt request:
Then we go to the external legs - external. Export them by double-clicking in the Double-click to export field:
For simplicity, I’ll call epcs so that less length is:
Now, with the usual hand movement, we assign base addresses:
And assign interrupts:
The automatically assigned address for our flash controller is 0 × 800 — we should remember:
He is still useful to us. And everything else, in principle, itself has become and will work.
Now it is very important, since we are not going to write a single line of our code so that the name of the processor system coincides with the name of the project. The project we had was flasher.
Save the system, call flasher:
That's when we have the top module is this processor, and therefore we do not have to do anything.
Our next step:
We leave everything by default, because we simply use what is already ready:
We finish:
There was a message that we need to remember to add the file to the project:
Let's add. Go to Project - Add / Remove Files in Project:
We find our file on the computer.
Here it is, our flasher file with the qsys extension.
Added it:
Now we make a draft compilation:
It ended successfully.
Now that it has passed, we can assign conclusions. Go to Pin Planner:
We do not need to assign JTAG legs - we assign the legs of a flash drive.
For each chip, for each case, they are their own. In principle, you can watch the documentation on the chip or on your board. For example, here we have the twelfth leg of the DCLK:
My list has already been prepared - just sort it out.
Thus, epcs_data0, LOCATION: PIN13, epcs_dclk - PIN12, epcs_sce - PIN8, epcs_sdo - PIN6. And specifically on the board of our customers the clock frequency PIN24, reset_n - PIN88.
Legs appointed. We start compilation. Errors are issued:
All because I pretended that I forgot to make a very important setting. We have now connected the flash drive to the service lines. And, at the end of the configuration, some of these lines are not available at all, and some are used for service purposes. Therefore, we were given messages that we have a conflict:
To eliminate this, go to Assignments - Device:
Device and Pin Options:
Here we select Dual-Purpose Pins. And at the end of programming we ask all these lines to be made with ordinary I / O lines:
Click OK, run the compiler. And everything turned out.
So the first step is complete. We have a configuration through which we can reach the flash drive.
Now our task is to make a file with which the system will recognize our flash drive.
We go to all programs, Intel FPGA (for older versions it will be Altera), Nios II Command Shell.
Here we go to the directory where we have just collected everything. At the same time, we don’t forget that the slashes here should not be inverse, but direct, and that the resulting flasher.sof file lies in the output_files directory:
Now we begin to cast magic spells. So, we need to pour in the newly formed configuration. For this we write:
nios2-configure-sof flasher.sof
and press Enter:
The file is full - now we have access to the flash drive. In order to determine everything related to access to the flash drive, we need to run the following program:
nios2-flash-programmer --epcs --base = 0x800 - debug.
where 0x800 is the same address that was automatically assigned to the epcs block and which should not be forgotten.
Press Enter:
What did he tell us? He tried to explore the area that we called. And at offset 0 at address 800 did not find anything. At address c00, he found what we need:
Now we remember not just the base address 800, but the specific address c00 - in the future we will work with it.
He found a flash drive, its ID is 202016, but said that he has no idea what to do with it because he does not know it.
Here is the documentation for our flash drive:
Its full identifier is 202016 - that is what it returns in response to a command requesting its code.
So everything is correct - the flash drive was found correct.
He tells us that there should be a file with the section EPCS-202016.
Wonderful. Edit - Mark. Select its name and take it to the clipboard.
Create an ovr.txt file and a section with the name you just copied:
In the documentation for our flash drive, in the section Memory Map, we can see that it consists of 64 sectors. Each sector has a size of 64 KB, because from 0000 to FFFF.
Therefore, the configuration file we just created should look like this:
64 sectors of 64 KB in size, or 65536 bytes each.
The second step is ready. We have the files flasher.sof and ovr.txt, which contains the configuration of the flash drive.
Go to the third step.
Let me remind you that the working draft was USB16_my. And the firmware file was called Test1.sof. We copy flasher.sof and ovr.txt to it.
Now we have completed all the preparatory steps - proceed to direct hostilities. To emphasize the lack of connection between training and work, I will enter the terminal again, as if it happens the next day, a week later, a month later, or any time after the completion of the preparation.
The first thing we need to do is generate an output file. Because the sof file is not stitched in ROM - a slightly different file is stitched. In order to form it, we write:
The file Test1.flash turned out:
Now, purely formally, came the turn of the actions that the board builders should do. First of all, they should also load our flasher, that is:
After which they must flash the ROM:
Actually, that's all. The problem is solved, the flash drive is stitched - you can use it, even though the main way was talking about the mismatch of ID-Schnick. And you do not need to buy expensive configurators at all or look for the supplier from which the 25th flash drives have compatible IDs. We prepared a “flash driver” for our specific board (and any others where the same crystal and Reset with the generator are connected to the same output), we prepared a text file for the configurator, and then we poured the “firmware” using the utilities supplied deliveries of Quartus Prime standard environment (they also came with Quartus II environment).
Source: https://habr.com/ru/post/352666/
All Articles