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

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

Marcus Harnisch over 12 years ago

Note: This was originally posted on 19th August 2009 at http://forums.arm.com

Thanks ttfn, this was the answer. I moved the interrupt clear instruction earlier in the handler and the problem disappeared.

Sure, but this is in no way better than adding a NOP instruction as you did earlier. If you want to be absolutely sure you'd have to declare that peripheral region as non-bufferable or use a "drain write buffer" barrier before returning from the ISR.

[url="http://infocenter.arm.com/help/topic/com.arm.doc.ddi0151c/Chebfdhc.html"]http://infocenter.arm.com/help/topic/com.a...c/Chebfdhc.html[/url]

Best regards
Marcus
Cancel
Vote up 0 Vote down

Cancel

Reply

Marcus Harnisch over 12 years ago

Note: This was originally posted on 19th August 2009 at http://forums.arm.com

Thanks ttfn, this was the answer. I moved the interrupt clear instruction earlier in the handler and the problem disappeared.

Sure, but this is in no way better than adding a NOP instruction as you did earlier. If you want to be absolutely sure you'd have to declare that peripheral region as non-bufferable or use a "drain write buffer" barrier before returning from the ISR.

[url="http://infocenter.arm.com/help/topic/com.arm.doc.ddi0151c/Chebfdhc.html"]http://infocenter.arm.com/help/topic/com.a...c/Chebfdhc.html[/url]

Best regards
Marcus
Cancel
Vote up 0 Vote down

Cancel

Children

No data