16-bit flash WR/Erase problems

Hi thosburke,

> Has anyone tried sharing a common databus and getting the flash to write/erase?

Yes. One of my boards does this -- it works.

> except trying to write to flash or erase a sector. If we do either of these things,

> linux hangs forcing a power cycle to reset things.

Just a guess ... but I've experienced similar problems -- it's related to the use

of the toggle-bit:

See: http://forum.niosforum.com/forum/index.php...wtopic=2302&hl= (http://forum.niosforum.com/forum/index.php?showtopic=2302&hl=)

You might want to check the chip driver you're using and make sure it uses

some technique _other_than_ the toggle bit (e.g. DQ7 polling). The last time

I looked at this, CFI command set 2 was ok -- but I never checked the

other chip drivers.

> The flash device is the AM29LV128 in word mode, i.e. 16-bit interface

BTW: The flash organization on my board was only 8-bits wide ... and it worked,

so I never needed to make sure the NIOS2 mods in the code were clean for

16-bit devices: drivers/mtd/chips/cfi_cmdset_0002.c

Regards,

--Scott

Scott:

We've tried several iterations with similar results. If we use the FLASH chip in byte mode, we can read fine, but not write/erase (crashes the same).

There are two methods to use the SDRAM -- one connects the busses inside nios, one connects the busses outside nios. Both techniques provide the same results as all the other methods.

If we just run a simple C application program out of SDRAM, and don't use uClinux, we can rd/wr/erase the flash just fine, in both byte and word mode.

If we run a simple assembly code application we can rd/wr/erase the flash just fine.

We'll take a closer look at the information you provided -- is there any specific setting we need to make in the kernel configuration that you can think of?

Thanks!

Hi thosburke,

> If we just run a simple C application program out of SDRAM, and don't use

> uClinux, we can rd/wr/erase the flash just fine, in both byte and word mode.

Then it's a software issue -- which is good ;-)

> is there any specific setting we need to make in the kernel configuration

> that you can think of?

Enable MTD debugging -- make it as verbose as possible. The boot can get

a bit tiresome ... but you might find some useful clues when you attempt to

erase/write.

BTW: how exactly are you erasing/writing via the kernel? mtd-utils? Or are

you using JFFS2 and doing a cp, cat, etc?

--Scott

We're using mtd_debug erase, which hits the MTD driver. The filesystem we want to use is JFFS2 . We have verified that we are correctly getting into the MTD driver code that actually flips the bits on the CFI interface.

Another clue: when we do an erase sector command, the processor hard crashes. But, once we power cycle the board, we see that the erase command was executed by the flash chip. And, sometimes the flash write works, but most times it crashes hard too. Total CPU lockup.

Did you have to make any modifications to the drivers or kernel to make your shared bus implementation work?

Thanks!

> And, sometimes the flash write works, but most times it crashes hard too.

> Total CPU lockup.

Is your exception address in the flash?

> Did you have to make any modifications to the drivers or kernel to make

> your shared bus implementation work?

No.

Exception address points to flash. D'oh!

We'll point at SDRAM and see what happens...

Thanks!

> Exception address points to flash. D'oh!

That's the likely culprit! Once an interrupt fires, the CPU tries to execute the current

value in the flash status register.

Man, I hate it when that happens! ;-)

Let us know how you make out.

Best Regards,

--Scott

Scott:

That was indeed the problem! Once we pointed the exception address to SDRAM, we could rd/wr/erase flash to our hearts' content, and get JFFS2 working.

This was dogging us for awhile, and I'm glad it was something so simple. Thanks for your help on this -- very much appreciated.

Regards,

TomB