- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 !Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes ...... (that was easy)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
<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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hello wombat:
Can you explain how to set the bit31 or IOWR_NATIVE maroc ? Thank you !- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
> Can you explain how to set the bit31
sometype_t *p = (sometype_t *)(ADDRESS | 0x80000000); Regards, --Scott- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's one way, or you add 0x80000000 onto the pointer (whatever gets that msb set).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
haha this post put me over the top (check out my status). Well that explains what comes next.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
sometype_t *p = (sometype_t *)(ADDRESS | 0x80000000);
#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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To BadOman & wombat:
What does the 31st do? I my flash has only 20 address lines, where is the 31st address line?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please read the posts at the start of the thread for information about what bit31 does. In short, it's a way for software to change the behaviour of the cache - it doesn't get to the external memory.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To wombat:
the code can be used to test any type flash? I use the AMD29LV320DT-90. Thank you!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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'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.- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page