robert lazarski wrote:
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.
Interaction with RAM size is unexpected. Time to quadruple check your OR/BR? Read out the registers directly with the BDI, don't trust nobody.
[snip]
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?
Whoo-heee!
No, the manufacture ID cannot be erased. Something odd is happening.
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
Whoo-heee!
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.
* Works only after waiting a minute? That's odd. Does your flash have a reset pin? Do you have a buffer (address or data) between the processor and flash with an enable pin? Are the reset/enables connected properly (not floating)?
* Detune (set to maximum delays) all the speed parameters in the BR/OR that controls flash.
* Use the logic analyzer to measure timing (tough nowadays with BGAs and fine traces).
gvb