[ECOS] strange flash write problems

Jürgen Lambrecht J.Lambrecht@televic.com
Mon Jun 19 09:40:00 GMT 2006

Hi guys,

I have a very strange software problem, but I know a workaround that I 
want to
share with you.
I start with saying it is a software problem because your first reaction 
probably be "it's a hardware problem", but it's not.

So my ARM7 board, based on the eb55 board, has a spansion flash 
(S29L512N) of
64 MB. I use 4 Chip-Selects (CS) to generate (with some logic) addresses A24
and A25. So each CS addresses 16MB. CS0 is mapped to address 
0x0200_0000, CS1
to 0x0300_0000, CS2 to 0x0400_0000, CS3 to 0x0500_0000; as you can see, the
addresses nicely follow up each other (16MB is 0x0100_0000 MB).

The problem I have is that redboot (and also a test application using jffs2)
cannot write to _addresses_ 0x0200_0000 and 0x0300_0000. The first 2 
sectors of
0x0200_0000 claims redboot to be write-protected, and all the other 
sectors of
0x02.. and 0x03.. give a time-out when writing to them.
Addresses 0x0400_0000 and 0x0500_0000 are writeable without any problem.

This is a software problem because
- only the highest sector can be (and is not) hardware write protected
- the lock and unlock functions are not implemented in the low-level driver
- !! When I swap the CS mapping to CS0-0x0400_0000, CS1-0x0500_0000,
CS2-0x0200_0000, CS3-0x0300_0000, then I get the same behavior: 0x02.. and
0x03.. are not writeable, but this time this agrees with the second half 
of the
flash which _was_ writeable before the swap !! So after the swap, 
suddenly the
physically first sectors of the flash are not anymore write protected, 
and no
time-outs anymore when writing the other sectors (of the first half of the
- I use BDI2000 of Abatron, a JTAG ICE debugger. And with this device I can
  write addresses 0x02.. and 0x03.. without problem.
- When I boot from EEPROM instead of flash, with of course the EEPROM at 
CS0, then address 0x0200_0000 is mapped (both in HW and SW) to CS5. But 
the write problems are the same.

When debugging with the BDI and gdb, we found that when redboot returns 
protected", then actually the read-out of the flash lock register fails:
instead of reading the lock register after the correct command sequence, we
just read the data of the flash. And when we remove the code that does the
lock-check, we get a time-out.
It seems like writing commands to the flash only succeeds to addresses
0x04.. and 0x05.. .

The workaround is to use another addresses mapping:
CS0 is mapped to address 0x1000_0000, CS1 to 0x1100_0000, CS2 to 
CS3 to 0x1300_0000 Now all write accesses are ok. Tested on many 
hardware with
different software releases.

Kind regards,

Jürgen Lambrecht
Development Engineer
Televic Transport Systems
Televic NV / SA (main office)  	
Leo Bekaertlaan 1
B-8870 Izegem
Tel: +32 (0)51 303045
Fax: +32 (0)51 310670

Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list