Arm Community
Site
Search
User
Site
Search
User
Groups
Arm Research
DesignStart
Education Hub
Graphics and Gaming
High Performance Computing
Innovation
Multimedia
Open Source Software and Platforms
Physical
Processors
Security
System
Software Tools
TrustZone for Armv8-M
中文社区
Blog
Announcements
Artificial Intelligence
Automotive
Healthcare
HPC
Infrastructure
Innovation
Internet of Things
Machine Learning
Mobile
Smart Homes
Wearables
Forums
All developer forums
IP Product forums
Tool & Software forums
Pelion IoT Platform
Support
Open a support case
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Developer Community
Tools and Software
Software Tools
Jump...
Cancel
Software Tools
Arm Development Studio forum
Bootloader problem in ARM926ejs
Tools, Software and IDEs blog
Forums
Videos & Files
Help
Jump...
Cancel
New
Replies
9 replies
Subscribers
127 subscribers
Views
3515 views
Users
0 members are here
Related
Bootloader problem in ARM926ejs
Offline
F Girault
over 7 years ago
Parents
Offline
Scott Douglass
over 7 years ago
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).
Cancel
Up
0
Down
Reply
Cancel
Reply
Offline
Scott Douglass
over 7 years ago
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).
Cancel
Up
0
Down
Reply
Cancel
Children
No data
More questions in this forum
By title
By date
By reply count
By view count
By most asked
By votes
By quality
Descending
Ascending
All recent questions
Unread questions
Questions you've participated in
Questions you've asked
Unanswered questions
Answered questions
Questions with suggested answers
Questions with no replies
Not Answered
DS52020.0 connection to Musca-A/B boards not working
0
Arm Development Studio
Musca-A
33
views
0
replies
Started
3 hours ago
by
Daniel Oliveira
Suggested Answer
Positioning a function in a Position Independent Executable for ARMV8
0
1656
views
3
replies
Latest
7 days ago
by
Stephen Theobald
Answered
Link a pure binary file to image with scatter file
0
1620
views
3
replies
Latest
7 days ago
by
Ronan Synnott
Answered
Failed to read contents of Internal RAM L1-I_DATA in ARM DS
0
Arm Development Studio
Cache
Debug and Trace Services Layer (DTSL)
4202
views
23
replies
Latest
20 days ago
by
Boon Khai
Suggested Answer
DS-5 connect fail when cortex-r5 is in lock-step mode
0
3873
views
10
replies
Latest
27 days ago
by
Stuart Hirons
>
View all questions in Arm Development Studio forum