On 9/12/07, David Hawkins dwh@ovro.caltech.edu wrote:
Don't move onto anything until you can read the manufacturer ID, you've found a problem, so you need to figure it out here first.
After a few days with the docs, we've had some limited success. We moved back to 128MB of ram and a base address of F8000000 . We think we may have some timimg issues. To read the manufactor id the docs say:
*( (UINT16 *)base_addr + 0x555 ) = 0x00AA; /* write unlock cycle 1 */ *( (UINT16 *)base_addr + 0x2AA ) = 0x0055; /* write unlock cycle 2 */ *( (UINT16 *)base_addr + 0x555 ) = 0x0090; /* write autoselect command */ manuf_id = *( (UINT16 *)base_addr + 0x000 ); /* read manuf. id */
So in our case we start with LAD30, so we need to do a shift left:
AAA = 555 << 1; 554 = 2AA << 1;
In the bdi, we executed:
ATUM>mmh 0xf8000AAA 0x00AA ATUM>mmh 0xf8000554 0x0055 ATUM>mmh 0xf8000AAA 0x0090 ATUM>mmh 0xf8000AAA 0x0090 ATUM>mdh 0xf8000000 1
At which point we got the manufactor id and everything else. Unfortunately the next day we weren't able to repeat it - can the manufactor id be erased?
Anyways, we were able to write a word:
ATUM>mmh 0xf8000AAA 0x00AA ATUM>mmh 0xf8000554 0x0055 ATUM>mmh 0xf8000AAA 0x00A0 ATUM>mmh 0xf8000F00 0xCAFE ATUM>mdh 0xf8000F00 1 0_f8000f00 : 0xcafe -13570
We have yet to be able to repeat that feat at any other address. We can read 0xCAFE from 0xf8000F00 , but only after about a minute after a bdi boot. We cannot overwrite 0xf8000F00 , nor can we erase the entire chip via the documented sequence. As I said we think we have timing issues. Any suggestions? More RTFM? We do have a logic analyzer.
Thanks all, Robert