• Locked Locked
  • Replies 9 replies
  • Subscribers 119 subscribers
  • Views 5633 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Bootloader problem in ARM926ejs

F Girault
Parents
  • Arm Employee Badge
    Note: This was originally posted on 25th June 2011 at http://forums.arm.com

    Are the caches on when your bootloader is copying the application from Flash to RAM?

    If yes, then you should clean the D cache (if it's write-back) and flush the I-cache before you jump to the application, because the copying happens as data.  During the copying the application area needs to be writeable.  Inconsistent cache problems can be hard or impossible to see in a debugger, because a debugger probably reads the code as data which might not match what the processor sees from the I cache.

    Also, when the application starts, is are the MMU and caches still on from the bootloader?  If so the application's "reset handler" may need to take that into account -- for instance when you disable the MMU there needs to be code at the same physical address as the virtual address it's just been executing from.

    Is your abort exception a data abort or prefetch abort?  You can only tell the difference by which exception vector was used.  If the abort was a data abort caused by the MMU then R14 will point a couple instructions past the offending instruction (see the TRM or ARM ARM for exact details) and more information (such as the address being accessed) is available in the DFAR and DFSR (again see the docs).
Reply
  • Arm Employee Badge
    Note: This was originally posted on 25th June 2011 at http://forums.arm.com

    Are the caches on when your bootloader is copying the application from Flash to RAM?

    If yes, then you should clean the D cache (if it's write-back) and flush the I-cache before you jump to the application, because the copying happens as data.  During the copying the application area needs to be writeable.  Inconsistent cache problems can be hard or impossible to see in a debugger, because a debugger probably reads the code as data which might not match what the processor sees from the I cache.

    Also, when the application starts, is are the MMU and caches still on from the bootloader?  If so the application's "reset handler" may need to take that into account -- for instance when you disable the MMU there needs to be code at the same physical address as the virtual address it's just been executing from.

    Is your abort exception a data abort or prefetch abort?  You can only tell the difference by which exception vector was used.  If the abort was a data abort caused by the MMU then R14 will point a couple instructions past the offending instruction (see the TRM or ARM ARM for exact details) and more information (such as the address being accessed) is available in the DFAR and DFSR (again see the docs).
Children
No data