On Sun, Dec 19, 2010 at 11:49 PM, Dirk Behme dirk.behme@googlemail.com wrote:
On 20.12.2010 07:07, John Rigby wrote:
The working assembly looks like this:
if (cmd != NAND_CMD_NONE) 80024d28: e3710001 cmn r1, #1 origwriteb(cmd, this->IO_ADDR_W); 80024d2c: 15933004 ldrne r3, [r3, #4] 80024d30: 120110ff andne r1, r1, #255 ; 0xff 80024d34: 15c31000 strbne r1, [r3] 80024d38: e8bd8010 pop {r4, pc}
The broken assembly looks like this:
if (cmd != NAND_CMD_NONE) 80024d28: e3710001 cmn r1, #1 80024d2c: 08bd8010 popeq {r4, pc} writeb(cmd, this->IO_ADDR_W); 80024d30: e5933004 ldr r3, [r3, #4] 80024d34: e20110ff and r1, r1, #255 ; 0xff 80024d38: e5c31000 strb r1, [r3] 80024d3c: e5d33000 ldrb r3, [r3] 80024d40: e8bd8010 pop {r4, pc}
Hmm. From functionality point of view, the 'broken' assembly below should to the same as the working assembly, above. The main difference is the 'popeq {r4, pc}' and the additional 'ldrb r3, [r3]'. The write to the HW 'strb r1, [r3]' is there, so it should work. Is this understanding correct?
If it's correct, the question is, what breaks the below assembly? The popeq or the additional ldrb? The popeq looks correct, but why is the additional ldrb there?
I can't answer why the ldrb is there but I'm pretty sure it is the problem. From the TRM http://focus.ti.com/lit/ug/spruf98m/spruf98m.pdf:
Only write accesses must be issued to these locations, but the GPMC does not discard any read access. Accessing a NAND device with nOE and CLE or ALE asserted (read access) can produce undefined results.
br, John