[ECOS] strange flash write problems

[ECOS] strange flash write problems

[Jürgen Lambrecht]

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 
will
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
  (devs/flash/amd/am29xxxxx)
- !! 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
flash).
- 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 
"write
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 
0x1200_0000,
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
http://www.televic.com
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

Re: [ECOS] strange flash write problems

[Socrates Socrates]

Hi Jürgen

Going through your (this) posting I figured you might just be the
person to rescue me.
Anyways, I am using the EB40 board (something close to your EB55 I
assume) and I am faliing to get redboot to boot.
I can go through the whole process of uploading (redboot.srec) onto
the board and also writing the firmware to the flash, but when I move
SW1 to UPPER_MEM to select redboot and then press reset, nothing
happens.

Any ideas? In fact, any way/method by which I can prove that the write
to the flash actually  works would be great.

Oh, I've asked this question on the forum some week or two ago but I
could not make any progress using the suggestions provided.


Regards;
Lawrence

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