Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorHow to use an EPCS Flash
Hallo together,
I'm actually trying to save data from NIOS II into an EPCS64 device. My system contains an EPCS controller. But now the confusion is complete, there are so many files for using an flash... and I'm not sure which to use. There are: - altera_avalon_epcs_flash_controller.h - sys\alt_flash.h - epcs_commands.h And all these headers include different read/write functions. Then I tried an example from the Internet to start.
static alt_flash_fd* epcs16_dev_ptr;
static flash_region *p_epcs_reg_info;
static int num_epcs_regs;
void epcs_open(void)
{
epcs16_dev_ptr = alt_flash_open_dev(EPCS_FLASH_CONTROLLER_NAME);
if (epcs16_dev_ptr == NULL)
{
alt_printf("** Can't open flash device **\n\n");
return;
}
alt_epcs_flash_get_info(epcs16_dev_ptr, &p_epcs_reg_info, &num_epcs_regs);
return;
}47 Replies
Altera_ForumOk, I couldn't really explain, but I recompiled the whole design, loaded it and it works!
Maybe there was some strange behavior anywhere... Thanks to all! Greets Sim- Altera_Forum
Hallo,
I'm already working on this problem. I could not get any data out of this flash. I recently tried to access the flash over a simple spi after booting. So I multiplexed the signals. I boot over EPCS controller and the the NIOS switches the the signal to a spi. Then I try to send an RDID command over the spi interface. With the oscilloscope I see, that the clock is right. Also the CSn and the Data signal seems to be right. But the Flash never answers... I tried the same withe a READ command -> no answer! Has anybody an idea about this behavior? Greets Sim - Altera_Forum--- Quote Start --- As I said in one of yesterday's posts M25PE16 and EPCS commands are faily compatible but the read indentification commands are different Since you are not willing to look at the datasheet (at least in order to know what the expected id should be), I'll explain here. EPCS use the command code 0xAB to read the silicon id (e.g. 0x14 for EPCS16) while on M25PE16 the same code is used for the release from power down command. Then, the hal driver function will get no id but only invalid data; actually they are all 1s, since the RDP command is not supposed to send any answer. The read-id command code for M25PE16 is instead 0x9F In conclusion, I guess I have to correct my previous statement: you can't get the silicon id but you probably will be able to read/write the flash device, since all other relevant commands are pretty compatible. --- Quote End --- Ok, I'm sorry if you are right. I maybe overlooked this in your last post. But I will investigate in this way the next days. If I have any news I will give a report here. Thanks!
- Altera_Forum--- Quote Start --- EPCS use the command code 0xAB to read the silicon id (e.g. 0x14 for EPCS16) while on M25PE16 the same code is used for the release from power down command. --- Quote End --- Probably you would be right, but from a Micron datasheet of M25P16, the "READ ELECTRONIC SIGNATURE and RELEASE from DEEP POWER-DOWN" command is exactly the one that epcs_read_electronic_signature function within original HAL driver use (i.e. res_cmd[] = {epcs_res, 0, 0, 0}) --- Quote Start --- The read-id command code for M25PE16 is instead 0x9F --- Quote End --- Exactly... that (epcs_read_device_id) is in fact the command issued by original EPCS HAL driver if previous epcs_read_electronic_signature command (ABh) fails answering something not foreseen. I think (again) that debugging you should be able to retrieve the answer to both command. If the second command is issued because the answer to first one is FFh, you will have to possibilities: 1) if the answer is still FFh you have to check you signal 2) if the answer is not FFh, you have to modify your HAL driver adding the support of M25PE64 because the original HAL driver only support EPCS128 (18h) as possible answer to epcs_read_device_id command. Ciao
- Altera_Forum
As I said in one of yesterday's posts M25PE16 and EPCS commands are faily compatible but the read indentification commands are different
Since you are not willing to look at the datasheet (at least in order to know what the expected id should be), I'll explain here. EPCS use the command code 0xAB to read the silicon id (e.g. 0x14 for EPCS16) while on M25PE16 the same code is used for the release from power down command. Then, the hal driver function will get no id but only invalid data; actually they are all 1s, since the RDP command is not supposed to send any answer. The read-id command code for M25PE16 is instead 0x9F In conclusion, I guess I have to correct my previous statement: you can't get the silicon id but you probably will be able to read/write the flash device, since all other relevant commands are pretty compatible. - Altera_Forum
Hallo,
I know about the fact that small driver will exclude the flash drivers. But like paolobbi said, I thought that# define ALT_USE_EPCS_FLASH will solve that problem. This is described in the embedded software development user guide in that way. Or had I misunderstood this?? Ok, 0xFF is an error. This brings me to the beginning of this thread :(. Any ideas how to find the problem? Greets Sim - Altera_Forum--- Quote Start --- id=0xff is definitely an error, since this means the data rx line is stuck to high level, namely the undriven state or, equivalent, the epcs_controller rx register contains invalid data. Then read and write operations will probably not work. --- Quote End --- I agree with you... --- Quote Start --- "small driver" feature has been selected, or if fast simulation has been requested --- Quote End --- Sim already posted that small driver are selected but he enabled ALT_USE_EPCS_FLASH; from an image he posted yesterday correct epcs init function is enabled.
- Altera_Forum
id=0xff is definitely an error, since this means the data rx line is stuck to high level, namely the undriven state or, equivalent, the epcs_controller rx register contains invalid data.
Then read and write operations will probably not work. Regarding the fact you need to perform those calls in main, please note this remark I found in altera_avalon_epcs_flash_controller.h header file just before ALTERA_AVALON_EPCS_FLASH_CONTROLLER_INSTANCE/_INIT definitions : /* * Macros used by alt_sys_init.c * * By default this driver is initialised in alt_sys_init. However if the * "small driver" feature has been selected, or if fast simulation has been requested * no initialisation is performed. * * This causes the driver to be excluded from the system (unless explicitly * initialised by the user from main()), and therefore reduces code footprint. * */ - Altera_Forum
I didn't know what my eclipse shows in debug mode, but nothing useful I think! :mad:
I now checked the silicon id with an simple alt_printf() and now I see, the id id 0xFF. Then I added a if statement for these id, and initialized the structure. And now the command alt_flash_open_dev(EPCS_FLASH_CONTROLLER_NAME) returns no error! :) I will check the next days if I now could really read/write the flash and give a report here. But one strange thing remains, I still had to call
in main(). This should be called automatically, or not? Can someone explain this behavior? Thanks SimALTERA_AVALON_EPCS_FLASH_CONTROLLER_INSTANCE ( EPCS_FLASH_CONTROLLER, epcs_flash_controller); ALTERA_AVALON_EPCS_FLASH_CONTROLLER_INIT ( EPCS_FLASH_CONTROLLER, epcs_flash_controller); - Altera_Forum
I suppose there is something wrong in how you modify and compile your source...
Which is the device id that device answer you? You should get this info debugging alt_epcs_flash_query() function. I continue thinking that the ID it would answer your should be already supported. I want to remember you that everytime you Generate your BSP, all your driver source within BSP folder are removed and retrieved again from altera IP or NIOS2EDS folder. Ciao
