read or write date through flash

[Altera_Forum]

hello 

  the below sentences is in flash_AM29LV065d.c .  volatile unsigned char *fb = (unsigned char *) flash_base;   fb[0x555] = 0xAA; // 1st cycle addr = XXX, data = AA    if the sentences run,the date of the address 0x555 in flash will be 0xAA ? I don't use the date cache and instruction cache.      Thank you !

[Altera_Forum]

Yes ...... (that was easy)

[Altera_Forum]

<div class='quotetop'>QUOTE </div> 

--- Quote Start ---  I don&#39;t use the date cache and instruction cache.[/b]  --- Quote End ---    If you mean by this that you are using a processor without a data cache then yes, you are correct.  If you mean that you are using a processow with a data cache but want to bypass it then you will need to set bit31 or use the IOWR_NATIVE macro instead.

[Altera_Forum]

hello wombat: 

   Can you explain how to set the bit31 or IOWR_NATIVE maroc ?     Thank you !

[Altera_Forum]

if you have data cache in your system then in order to access a peripheral you must either set the 31st address bit high or use the IORD and IOWR macros (which set the 31st bit high). When the 31st bit is high the Nios will bypass the data cache and directly access the peripheral (periphals you do not want to be cacheable). So with this 31st bit determining the caching, you effectively have 2GB of address space (cacheable and non-cacheable). 

 If you don&#39;t perform cache bypassing with something like a hardware peripheral that you always read from you will get the following behaviour  First read will access the peripheral and read data from it Second read will not access the peripheral and the read data will be the same as in the first step (since the data is cached).  Hope that helps.

[Altera_Forum]

> Can you explain how to set the bit31  

 sometype_t *p = (sometype_t *)(ADDRESS | 0x80000000);  Regards, --Scott

[Altera_Forum]

That&#39;s one way, or you add 0x80000000 onto the pointer (whatever gets that msb set).

[Altera_Forum]

haha this post put me over the top (check out my status). Well that explains what comes next.

[Altera_Forum]

sometype_t *p = (sometype_t *)(ADDRESS | 0x80000000); 

This will work only if ADDRESS is of type int - otherwise the compiler should complain.  But there is a HAL function which will do this for you (and will correctly flush the cache if required at the same time):  #include <sys/alt_cache.h> sometype_t *p = (sometype_t *)alt_remap_uncached(ADDRESS, LEN); Using the HAL function guarantees that your code will work on all future processors, even if they use a slightly different method for marking pointers or memory areas as uncached.  note that adding 0x80000000 onto the pointer will only set bit31 for pointers of type char *. for all other pointers it will do nothing on a 32 bit processor such as nios2 (the arithmetic will overflow).

[Altera_Forum]

I would also use IORD and IOWR just so your code is easier to read (if someone sees you doing some strange pointer masking or math it may not be the easiest read for another fellow developer). 

 And as Wombat stated you have to be careful with your types as well when you do this (so I would just stick to the IORD and IOWR since they are well tested).

[Altera_Forum]

Yes, in 99% of cases using IORD and IOWR will be more obvious and just as fast. 

 The only case where it might be a good idea to use the bit31 method is where you are passing a pointer to another function (such as memcpy) which wouldn&#39;t otherwise understand that it is copying from uncacheable memory.  But note that you must never use the bit31 method for accesses to native bus aligned registers, as this might not work in future.

[Altera_Forum]

To BadOman & wombat: 

 What does the 31st do? I my flash has only 20 address lines, where is the 31st address line?

[Altera_Forum]

Please read the posts at the start of the thread for information about what bit31 does. In short, it&#39;s a way for software to change the behaviour of the cache - it doesn&#39;t get to the external memory.

[Altera_Forum]

To BadOman & wombat: 

   I think that transfering data to\from the flash can use some routine to carry out .For example in niosI the routing amd29Lv065.c can do this . But in the routing there are not the above problems.    fb=ext_flash_base;   fb[0x55]=0xAA; the above two sentenses can realize flash writing easily.   the cache problem still exists ?

[Altera_Forum]

The Nios I code will not work on Nios II because the cache architecture is different, and because the software infrastructure is different. 

 If you want already written code to program the flash then please look at the code in the altera_avalon_cfi_flash component - accessed through the header file sys/alt_flash.h (in altera_hal/inc)

[Altera_Forum]

To wombat: 

   the code can be used to test any type flash?  I use the AMD29LV320DT-90.      Thank you!

[Altera_Forum]

The altera_avalon_cfi_flash component should work with any CFI compliant flash which supports programming algorithm 1, 2 or 3. You should check the datasheet for your device to see whether it supports CFI. 

 Unfortunately a small percentage of older flash devices claim to be CFI compliant but actually aren&#39;t. Most of the new ones are OK.  But I would expect this flash to work correctly because its from the same family as the 29LV065 which is on the development board.