Forum Discussion
Honored Contributorread or write date through flash
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 !16 Replies
Altera_ForumYes ...... (that was easy)
- Altera_Forum
<div class='quotetop'>QUOTE </div>
--- Quote Start --- I don'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'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'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
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):sometype_t *p = (sometype_t *)(ADDRESS | 0x80000000);
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).#include <sys/alt_cache.h> sometype_t *p = (sometype_t *)alt_remap_uncached(ADDRESS, LEN); - 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'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.
