Nios II software bugging

[Altera_Forum]

I'm working with Nios II processor and quartus 10.1sp1 on the device cyclone III, using the EPCS64 flash memory. 

I've some problems when I send several commands of a sudden to the Nios software, for example to read or write.   I'm using the following Nios II C code from altera in my software implemented in my flash : alt_epcs_flash_read(p_epcs_fd, (void*)buffer, number_of_datas) -> to read data(s) alt_epcs_flash_write(p_epcs_fd, (void*)buffer, number_of_datas) -> to write data(s)   If I send severals commands of a sudden to my Nios software, this one works for few seconds answering to my commands (like read or write bytes in my flash) and after this it bugs and the Nios software is out of service. So I've put usleep(10000) in my C computer programm sending commands to Nios software, sometimes with this timer of 10 ms it works great I've no problem, I can send several commands without problem and receive messages from software without to see this one bugging, and sometimes it doesn't work and after this the Nios software doesn't answer at any of the command I send to him.  Do you have any idea how to solve this problem, didn't find a solution in altera datasheets.

[Altera_Forum]

Hi, 

Writing to a FLASH EEPROM Memory takes many milliseconds :  because you can't directly write to one byte in FLASH, you (more precisely alt_epcs_flash_write function) needs to read the sector in which the byte is located, then copy to RAM, then modify the byte at correct address, then write all sector from RAM to Flash.  And changing bit in Flash takes a few time (to provide sufficient current to level up the floating grid in the sillicium), so changing thousand of bytes takes thousand of this few time.  Whereas reading from FLASH takes less than 100 nano seconds  You have limited writing operations to flash : 100000 or 1 million.  If you change bits very often : for example 100 times a second, the FLASH will be guaranted to be written only for 1000 seconds (or 10000 seconds), equals 16 minutes (or 2 hours and 46 minutes respectively).  One "solution" is to use a cache.  EDIT : Quartus 10 and Quartus 11 are transitional version from SOPC to QSYS. If you use Qsys, take Quartus version 12 minimum.

[Altera_Forum]

Ok, get it for writing to the FLASH that it takes a few ms, I noticed that everything works great when I place a timer of 10 ms before to write again in the FLASH, but with the alt_epcs_flash_read(...) like it takes only 100 ns to read datas from FLASH I shouldn't use a timer then, or a timer of 1ms for example but it doesn't work after awhile and the Nios software doesn't answer at any of my command, I noticed that when I place a timer of 1s everything works great for reading but it's very too long, do you have any idea how to solve this problem mmTsuchi ? 

And how do you use a cache ?

[Altera_Forum]

Erasing a flash sector (sets all the bytes to 0xff) is likely to take 100ms or so, and writing every location (which can only clear bits) getting on for the same time. 

IIRC no other accesses to the flash can be done while a write (of an individual word) or an erase is taking place. I don't know how the altera functions work, the write is almost certainly synchronous, the erase might not be.  I'd try running your software with the actual flash writes commented out (or test using SDRAM instead) and replaced with spin-loop delays, you might find you have a simple logic problem.

[Altera_Forum]

I guess you write to Flash inside an interrupt routine. Bad Idea, interrupt routines should be as short as possible. 

Writing to Flash should be done in main program (or in a function) and should not be interrupted.  A cache is simply a portion of RAM you allocate, and you copy sometimes to Flash. It can be seen also as a buffer memory like in hard drive, optical drive...