In message B32437B1-F4F0-11D8-84C7-000393C7979E@student.unsw.edu.au you wrote:
I'm stepping through the code using a Multi-ICE, and am able to reliably read the flash, downloading the entire program, etc, so I'm fairly certain that the flash is hooked up and working ok. I can also disassemble this using arm-linux-objdump, and get some sane-looking output (1st 1000 lines clagged below).
Do yuou actually expect us tp read this? 1000 lines of dubious stuff without any explanation what to look for or so? Gosh!
work pretty well up until the point (at address 0x550) where it loads a particular register's address into R3 (e.g. ldr r3,0x00000744). It seems to load the top 16 bits without any worries, but the bottom 16 bits are FFFF (rather than the bottom half of the address of the OS counter register).
You mean a ldr statement is not woprking correctly? Are you 100% sure? Or is there a chance that the Multi-ICE is showing bad register contents?
I had a quick look back at what it does when its setting up the GPIO registers, and it seems that it happens sporadically while its doing any ldr instruction. It doesn't seem to be correlated with the address, and looking at the disassembly, the correct values are being read by the processor.
What has the disassembly to do with the values read by the processor? It may be what you _want_ to be read by the CPU, but what do you actually see on your data bus?
Is there anything different that the ldr instruction would do (as opposed to when I'm reading it out with multi-ice?) that might cause this effect?
Timing, for example. Also it may use bursts to fetch the data into cache. Depends on your configuration and system setup which you don't bother to share with us.
Before I noticed this problem, I was getting prefetch faults, and unknown instruction exceptions on a mov instruction (hence the addition of the nops at 0x56c to see whether it was dependent on the address - the addition of the nops caused the code above it to break in the way I described above.
Sounds like a misconfigured system and/or broken hardware.
Any ideas? Any further information that I can provide that might shed some light on the situation? I've attached the memsetup.S file that all this is generated from (from address 0x444 onward).
And do you really expect that we check this without any explanation what it wwas derived from, what you changed and why, what your hardware is looking like etc.?
I stopped looking when I saw that your changes violate the Codiing Style requirements as specified in the README.
You're sending 40kB of trash to the list, and expect that we solve a problem for you without being given any relevant data?
Sorry, this is not the way it works.
Best regards,
Wolfgang Denk