Storing non-volatile data on-board

[Altera_Forum]

Hello guys, 

 I am doing some task that requires me to store some volatile data on board my dev board.... i am using de2-70 board..  Anyway i can do this?  BTW i am using the flash to store my codes permanently hence the only other choice would be to use the SDcard but i dont know how.... anyone have used the sdcard to store data before?  Pls Help

[Altera_Forum]

If there is an unused portion of the flash, you can use that. 

 Jake

[Altera_Forum]

I have read the hal library for flash by altera, my question is how can i find the correct address to start write my codes and in the same time not to corrupt the program code stored together in flash

[Altera_Forum]

--- Quote Start ---  I have read the hal library for flash by altera, my question is how can i find the correct address to start write my codes and in the same time not to corrupt the program code stored together in flash  --- Quote End ---    Facing the same issue... how to find the correct address where i can write some data into EPCS flash.

[Altera_Forum]

--- Quote Start ---  how to find the correct address where i can write some data into EPCS flash.  --- Quote End ---    The "correct" address is to start where locations are not used :)  That location depends on how you have configured your FPGA image. For example, if you turn compression on for generation of the EPCS programming image, the number of flash locations is smaller than if compression is off. However, if using compression, the "correct" location in flash for your data will change.  Page 12 of the SRunner application note (AN418) indicates that the image length in flash is located where there is all 0xFF values. However, the last 36 bytes are part of the flash image, so you cannot overwrite those.  My recommendation;  Starting with Flash that you've just written a configuration image to (but never written custom data to):  1) Start at the end of flash 2) Loop backwards comparing data to 0xFF 3) When you get a mismatch, go forward 36-bytes of 0xFF 4) Round up to the nearest 256-byte page 5) Write a 'magic' code, i.e., a series of header bytes 6) Start using that as your personal flash area.  The next time you go to look at the flash, you can start searching from the end going backwards in 256-byte blocks looking for your magic header.  Rather than doing steps 1-6 above, your code would actually just search for the header on 256-byte blocks, and then when it finds data that is not 0xFF and not the header, it would know that you have never written custom data to the flash, so it could jump forward 256-bytes, where the data is 0xFF, and start from step 2/3, i.e., go and find the end of the configuration image.  The Quartus programmer erase EPCS flash (at least when operating in AS mode), so you'll lose your data when you program a new configuration image.  Cheers, Dave