I have searched tediously through the forums for any help on this, and have tried a lot of different things. I am using the same Flash chip as on the NIOS II Cyclone II Eval board on a custom design; the AM29LV128REI (16-bit design in 8-bit mode). When I run nios2-flash-programmer --debug, it reads the CFI table, however, only a few bytes are a wrong, and it always seems to be the same bytes. I tried extending the timings to make them longer, and this changes the results, but it&#39;s still not correct. Sometimes, when it reads it correct, I can&#39;t program it, I get verify errors. I have used SignalTap to try and see what&#39;s going on, and it hasn&#39;t helped narrow down the problem. For example, when reading one of hte bytes from the CFI table, the address gets setup correctly, CEn goes low, then OEn a few cycles later. Sometimes, this doesn&#39;t produce the proper value; instead, the value shows up on the next cycle (address+1). On a 16-bit device in x8 mode, the reading of address and address+1 should be the same value. Since the software probably latches data in on the first reading, it is sometimes wrong. Anyway, it&#39;s hard to picture this being a signal-integrity problem since it&#39;s such low speed, and it&#39;s not even that far away. Any hints on debugging this?

You can try download a program into dram, and try out flash read write from dram. So that you can isolate if it is a jtag problem or others. You can try to set io pin current stength to minimum. The jtag singal is weak. You should also try add series terminator / pull high to jtag signals.

--- Quote Start --- originally posted by jdhar@Feb 22 2006, 07:27 PM on a 16-bit device in x8 mode, the reading of address and address+1 should be the same value. <div align='right'><{post_snapback}> (index.php?act=findpost&pid=12894) --- quote end --- --- Quote End --- I do not use AM29LV128M, but I think, that&#39;s not correct, because in BYTE mode A0 should be connected to (D15-A-1) of the flash (see Texas_rev01_sch_production.pdf in ..\documents\nios_cycloneII_2c35 of nios 5.1 best regards

--- Quote Start --- originally posted by hippo@Feb 22 2006, 08:35 PM you can try download a program into dram, and try out flash read write from dram. so that you can isolate if it is a jtag problem or others. you can try to set io pin current stength to minimum. the jtag singal is weak. you should also try add series terminator / pull high to jtag signals. <div align='right'><{post_snapback}> (index.php?act=findpost&pid=12896) --- quote end --- --- Quote End --- Hey hippo; I don&#39;t see how setting the current strength to minimum will help JTAG? I can&#39;t set the signal strengths on the JTAG pins (I don&#39;t think). And I don&#39;t think JTAG is the problem since I Can download code and run from DRAM without problem, as well as use Signal Tap. Also, I have tried what you said, reading/writing Flash from DRAM, and similar errors happen; I can confirm that errors I see with SignalTap are the same errors detected in code. I have also replaced the chip, so it&#39;s not the chip... and the circuit is a duplicate of what is on the Cyclone II dev board (just for some more info)

--- Quote Start --- originally posted by fischer+feb 22 2006, 08:47 pm--><div class='quotetop'>quote (fischer @ feb 22 2006, 08:47 pm)</div> --- quote start --- <!--quotebegin-jdhar@Feb 22 2006, 07:27 PM on a 16-bit device in x8 mode, the reading of address and address+1 should be the same value. <div align='right'><{post_snapback}> (index.php?act=findpost&pid=12894) --- quote end --- --- Quote End --- I do not use AM29LV128M, but I think, that&#39;s not correct, because in BYTE mode A0 should be connected to (D15-A-1) of the flash (see Texas_rev01_sch_production.pdf in ..\documents\nios_cycloneII_2c35 of nios 5.1 best regards <div align='right'><{post_snapback}> (index.php?act=findpost&pid=12897)</div> [/b] --- Quote End --- I can&#39;t tell what you mean exactly by your post; but I have the D15 pin as A0, and then A0 on the Flash is really A1, A1 is A2 etc... I think I forgot to mention it, but the addresses are doubled. So if in the datasheet, a CFI table parameter is at address 0x20, this is word address 0x20, but the value is only a byte wide. So in x8 mode, you have to read from address 0x40 (this is taking into account teh shift of address lines).. but 0x41 will read the same value again. If you want to read word at 0x21 in x16, you need to read byte 0x42. I hope that wasn&#39;t too confusing.. it&#39;s hard to put into words. As I mentioned, the circuit is a duplicate of the Cyclone II dev board, and they have A0 connected to the DQ15 pin.

For current strength, I meant flash io pins. Lower current stength will lower slew, and lower noise. Try running a read/write flash loop from dram, and hook up scope to check the addr/data/cmd waveform. Did you use uncached access?

Parallel Flash Problems | Altera Community

16 Replies

Altera_Forum
Honored Contributor
20 years ago
--- Quote Start ---
originally posted by liangyi@Feb 23 2006, 01:50 AM
hi,
i look the flash schematic, nothing wrong.
have you checked the flash soldering?
does flash pins have short circuit?
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12910)
--- quote end ---

--- Quote End ---

I am very good at soldering, and have also tried two different chips, so it is highly unlikely that I soldered it wrong twice. I will check this again of course.
Altera_Forum
Honored Contributor
20 years ago
Other than 0x5a, which other addresses fail?
Altera_Forum
Honored Contributor
20 years ago
--- Quote Start ---
originally posted by queisser@Feb 23 2006, 04:05 PM
other than 0x5a, which other addresses fail?
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12925)
--- quote end ---

--- Quote End ---

That's what is odd - the whole CFI table is correct except that address.

here's some more info:

I made my own independant Verilog core to read the whole CFI Table, no NIOS processor or RAM or anything else... and it reads it flawlessly multiple times. This would indicate some sort of Signal-integrity error... when I add the nios processor, DDR etc.. that's when that byte starts to go weird. But no highs peed components are next to the Flash, so I don't understand why it would be an SI issue.

Here's something else: If I program the flash, it says verify failed... but I canr ead back the data and visually see that it matches what it should, so I think it's probably failing because of the same byte. If I had the source code to nios2-flash-programmer, it would help, but I don't. I programmed a .flash file with a boot copier in it, powered the board on, and it successfully booted and ran the code! I don't get why it's saying it failed then.

All in all, this problem has too many contradictions!
Altera_Forum
Honored Contributor
20 years ago
--- Quote Start ---
originally posted by jdhar+feb 23 2006, 04:09 pm--><div class='quotetop'>quote (jdhar @ feb 23 2006, 04:09 pm)</div>
--- quote start ---
<!--quotebegin-queisser@Feb 23 2006, 04:05 PM
other than 0x5a, which other addresses fail?
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12925)
--- quote end ---

--- Quote End ---

I made my own independant Verilog core to read the whole CFI Table, no NIOS processor or RAM or anything else... and it reads it flawlessly multiple times. This would indicate some sort of Signal-integrity error... when I add the nios processor, DDR etc.. that's when that byte starts to go weird. But no highs peed components are next to the Flash, so I don't understand why it would be an SI issue.
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12926)</div>
[/b]
--- Quote End ---

Spooky!

Can you put a signal analyzer or scope on the physical pins themselves and look at the timing difference between the plain Verilog and NIOS system?

Also, is it clock frequency dependent?
Altera_Forum
Honored Contributor
20 years ago
Definitely spooky... unfortunately, I don't have access to tools such as LAs or Scopes... they would really be helpful now though! it seems more like the internal fabric fo the FPGA screwing things up. I would be extremely surprised if this were a pure SI issue since it's such low speed, and it's very close to the chip (about 1"). I think I'm going to write my own flash programmer so I can see what is failing and what isn't; alteras Flash programmer doesn't give nearly enough info.
Altera_Forum
Honored Contributor
20 years ago
ok, this just got really weird:

I decided to make my own flash programmer using NIOS II, but without the HAL routines (just using IORD/WR_DIRECT). Since I have a x16 chip in x8 mode, I use the Write buffer command to write 16 bytes.. very simple. I wrote them starting at address 0x0, which is the reset address... if I write 16 bytes with NO 0xFFs, and reset the board, I can see the processor reading all 16 bytes correctly. However, if I program an 0xFF at byte location 3 for example, upon reset, all the other bytes EXCEPT 0x3 read correctly! This makes no sense! I'm erasing the sector before programming... but for some reason, when it gets to the address location that I tried to program an 0xFF in, the data lines just go crazy. It reads all the other bytes with no errors.

To get around this, I tried filtering out 0xFFs in code.. if I see an 0xff, I simply don't write to that location.. that doesn't work either. If I erase the whole chip, I can see 0xFFs being read fine.. but as soon as I program something around a 0xFF without touching it, it gets garbled up.

Forum Discussion

Parallel Flash Problems

16 Replies

Recent Discussions

NIOS SDK SBOM/FOSS info

JTAG_UART stuck in printf

Recommended Quartus Prime Standard Edition for Nios V Development on MAX 10 FPGA (10M25DAF4817G)

University Program IP for NiosV

NiosV µC/OS-II