Hi,In message <mpro.lo0ztm00bgzuf006s@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Jeremy Nicoll - zf freelists <jn.fr.lsts.74@xxxxxxxxxxxxxxxxxxxx> writes
Are there any times when that's not true (it's ages since I read anything about ARM assembler). ISTR it's something to do with pipelining in the CPU? Might that work differently in the ARMini's processor?
Good point. I'd like to move the site of the crash away from this code to somewhere more favourable for bugs, the trouble is the register values point to this location.
So the LDR R5... is the instruction being executed? If you put these two LDR instructions in the opposite order does the crash happen 4 bytes earlier (as you'd expect if the instruction itself or the address it references is the problem)?
We're looking at the output of the C compiler, but yes I could edit the assembler output and recompile it.
There is the external change theory, the memory has been paged out or read protected - seems unlikely unless the ARMmini has a 1K page size.Why 1K?
Because the R5 load is from an address in another 1K page (I thought).
To me, the thing that's striking about the memory locations in these two instructions is that the LDR R6 refers to address &0008FB24 (just a bit less than &8FFFF) whereas the LDR R5 has &00090490, which is just a bit higher in memory? Any multiple of &10000 is a 64K boundary so presumably a 1K, 2K, 4K, 8K, 16K... or 64K page size boundary could be relevant?
Yes but the R6 load is not the one that fails. The code is at 00090434, so we're in the memory above 90000, so it is OK.
Would using !Reporter's SWIs be friendlier?
Don't know I'd have to investigate.I might just be in trouble here because of using new things like showregs. Should have used printf...
-- David Pilling email: david@xxxxxxxxxxxxxxxxxxx web: http://www.davidpilling.net post: David Pilling, P.O. Box 22, Thornton-Cleveleys, Blackpool. FY5 1LR. UK To unsubscribe or subscribe goto: //www.freelists.org/list/davidpilling