double write pulse using only one single IOWR_16DIRECT

[Altera_Forum]

Hi, 

I've hooked up a CFI flash (8MB) to the Tristate bus. I've managed to get the CFI query working, however, I can't write to the flash at all.  Observing the bus, I've found out that every IOWR creates 2 pulses of Write_enable. And I suspect that this creates a problem, because the statemachine in the flash can't get into the right state.   Why does 1 IOWR_16DIRECT create 2 pulses of Write_enable? (It should be only 1) Am I right?  --- My hardware and softare configuration:  Flash: located at 0x4000000, 22 bits address, 16 bit data I've tried with both Quartus 8 and 9.  ---  Have you encountered similar issues? Please help!!! Thank u!  Regards,  Jeff

[Altera_Forum]

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

[Altera_Forum]

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?

[Altera_Forum]

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

[Altera_Forum]

@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 lieumychuong@gmail.com if you need me to give you the reference codes.

[Altera_Forum]

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!!

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

--- 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?

[Altera_Forum]

--- Quote Start ---  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?  --- Quote End ---    Hi,  Maybe you can escalate the issue to Altera Support. If you're still fresh about the issue, you may send them the archive of your project for them to "reproduce". Hopefully this will solve the bug.

[Altera_Forum]

--- Quote Start ---  Hi,  Maybe you can escalate the issue to Altera Support. If you're still fresh about the issue, you may send them the archive of your project for them to "reproduce". Hopefully this will solve the bug.  --- Quote End ---    That what I probably have to do, but I am too lazy to start answering questions like "Did you try 10.0 SP22?, Did you reproduce in latest hottest 10.0.0 preliminary beta?" etc, etc....  Now to the good news. We found a workaround.  Just insert Avalon-MM pipeline bridge without burst support between in between NiosII CPU and cfi flash. The bridge converts single-word burst writes coming from the CPU which are triggering the bug into regular 32-bit writes with properly set byteenables that altera_avalon_cfi_flash module capable to deal with.  That's actually was easy. Doesn't compare with obscure, hard to reproduce, DDR2 on Arria2GX problems that I am fighting for majority of the recent week :cry:

[Altera_Forum]

--- Quote Start ---  That what I probably have to do, but I am too lazy to start answering questions like "Did you try 10.0 SP22?, Did you reproduce in latest hottest 10.0.0 preliminary beta?" etc, etc....   --- Quote End ---   lol, can't agree any stronger (or more strongly?!? :D).

[Altera_Forum]

--- Quote Start ---  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  --- Quote End ---      Hallo,  I have an similar problem. I would like to connect a memory mapped slave, with a 16-Bit wide data interface to the nios ii. Then I do the IOWR_16DIRECT() operation from nios and try to set some registers inside the slave depending on the addresses.    Unfortunately addressing fails. Maybe the multiple write operations causes this.    Now I extend the data interface to 32-Bit and use IOWR() (ignoring the upper 24 bits) -> everything works fine.    surprisingly (http://www.dict.cc/englisch-deutsch/surprisingly.html) the IOWR_8DIRECT() method works fine. I use it several times to access registers of slaves with a 8-Bit wide data interface.    Could somebody explain this behavior? :confused:     Greets  Sim

[Altera_Forum]

The nios cpu always does 32bit master accesses, so if your slave is narrower than 32bits a 'bus width adapter' is added - that converts the single 32bit cycle into 2 or 4 cycles with the approprate byte enables asserted. 

 Moreover the nios always asserts all 4 byte enables on reads.  You really are better off writing a 32bit wide slave.