Arm Community
Site
Search
User
Site
Search
User
Support forums
Arm Development Studio forum
Pipeline issue on return from FIQ
Jump...
Cancel
Locked
Locked
Replies
7 replies
Subscribers
119 subscribers
Views
5119 views
Users
0 members are here
Options
Share
More actions
Cancel
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
Pipeline issue on return from FIQ
Freddy Freddy
over 12 years ago
Note: This was originally posted on 17th August 2009 at
http://forums.arm.com
I'm using an ARM9 (Cirrus EP9302). My FIQ interrupt handler returns using "subs pc, lr, #4" instruction. The way the handler was originally written, the previous instruction was an "str r9,[r8]" with r8 pointing to some I/O. This version crashes in all kinds of ways. Inserting one "nop" instruction, before the "subs" solves the problem.
This looks to me (but I'm not sure) as if the switching of the FIQ registers happens while the "str" instruction is still in progress, and it stores to whatever address the normal (supervisor) mode r8 points to. I could not find any documentation of the pipeline behavior during return from FIQ interrupt.
I have a working solution, but I don't like when I don't understand how it works. It may rise again behind me and bite...
Any help?
Parents
Freddy Freddy
over 12 years ago
Note: This was originally posted on 20th August 2009 at
http://forums.arm.com
Thanks Marcus, but my I/O range is neither buffered nor cached. The problem is (as ttfn wrote) that the execution pipeline does not finish the write operation for couple of cycles, leaving the interrupt enabled passed the return from interrupt instruction.
Eliminating the "nop" saved one cycle, which is significant for a handler executing as often as mine.
Cancel
Vote up
0
Vote down
Cancel
Reply
Freddy Freddy
over 12 years ago
Note: This was originally posted on 20th August 2009 at
http://forums.arm.com
Thanks Marcus, but my I/O range is neither buffered nor cached. The problem is (as ttfn wrote) that the execution pipeline does not finish the write operation for couple of cycles, leaving the interrupt enabled passed the return from interrupt instruction.
Eliminating the "nop" saved one cycle, which is significant for a handler executing as often as mine.
Cancel
Vote up
0
Vote down
Cancel
Children
No data