double write pulse using only one single IOWR_16DIRECT

Okay,

Here's what I found out!

When having a 16-bit device mapped to 32bit nios via tristate-bridge, every IOWR_16DIRECT will initiate 2 accesses to the device. Ex: IOWR_16DIRECT to 0x04 will write to location: 0x04 and 0x06.

My question is: is my observation true? Why is it designed that way? If it is that case, the CFI-flash will go crazy because all the command sequence will go wrong. I'm sure that someone already succeeded in getting the CFI flash working. How to work with CFI-flash ????

... Any reference design available?

Thanks a lot.

Jeff

Can you describe how did you connect your Flash?

i have a problem: i can't even read from Flash.

so would be so kind to explane: your pins of Flash are they input or output?

can you make a screenshot of pins in top-level og quartus?

Bingo,

Problem solved ... Here's what I did:

Delete the NIOS processor and instantiate it again ... working fine ...

I've been using the NIOS created by my colleague using SOPC 7.2 --> the CFI Flash doesn't work ... because of the double write access ...

Now, I just deleted the NIOS and instantiate a new one --> working fine ...

In both cases, I always use SOPC v8 sp1.

...

Can any expert tell me what is going on underneath? .... This thing was really tiring!!!

Regards,

Jeff

@dim: attached image for your reference: up_a[1] ==> connected to LSB of your Flash depending on the mode of operation.

Jeff

contact me at [email protected] if you need me to give you the reference codes.

FYI, turning on the Data Cache Burst option causes the problem.

Turning off this option solves the problem

I guess there is a bug somewhere which made me sratch my head ... really hard!!

Hi Jeff,

When the software team wrote the nios2-flash-programmer utility, how did they get past the problem? Did it not come up internally? Also, is there a possibility of getting the source code for flash programmer?

Thanks,

Steve

You won't be able to program flash if there are any other cycles during the programming sequence.

So you must use cache bypass instructions.

Also you must stop any data in the cache being written back - eg by being displaced to make way for more data.

So you'll need to (at least partially) flush the data cache.

Also I believe you'll always see two cycles on a 16bit peripheral since the nios always does 32 bit cycles. I don't think the bus bridges supress the cycles which have no active byte enables.

No one complained about this. I believe that this occurs uniquely to my SPOC system which was created since version 7.2, then migrated to 8.0. Some setting causes the thing to happen. I had to work around by having some and/or logic together with the write enable/byte enable to suppress the second pulse.

It's quite wierd.

Thanks :)

If i start every thing from scratch in version 8.0, it works perfectly.

Hi Jeff,

I got my system to work by turning off the data cache 'enable bursts'. I have been using 9.1 for my compiles. When you started from scratch, does your system have the 'enable bursts' turned off?

Anyway, having the data cache write back bursts turned off is o.k. in my system.

Thanks for the help,

Steve

--- Quote Start ---

FYI, turning on the Data Cache Burst option causes the problem.

Turning off this option solves the problem

I guess there is a bug somewhere which made me sratch my head ... really hard!!

--- Quote End ---

Half a year later.

Today we encountered exactly the same SOPC bug.

Unlike your case, for us Data Cache Burst is important since we plan for heavy use of DDR SDRAM. So your workaround wouldn't work for us.

Of course, we can manually edit SOPC builder generated file multiplying chip select by byteenable, but it's ugly and doesn't fit our development process.

Is there a hope for actual bug fix?

Or, may be, less ugly workaround that will allow us to use both dcache bursts and cfi flash at the same NiosII CPU?