This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001238] New: Thumb mode return from ISR causes undefinedbehaviour
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-bugs at ecos dot sourceware dot org
- Date: Wed, 18 May 2011 09:31:48 +0100
- Subject: [Bug 1001238] New: Thumb mode return from ISR causes undefinedbehaviour
- Auto-submitted: auto-generated
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001238
Summary: Thumb mode return from ISR causes undefined behaviour
Product: eCos
Version: CVS
Platform: at91sam7xek_512 (AT91SAM7X-EK board with AT91SAM7X512)
OS/Version: ARM
Status: UNCONFIRMED
Severity: critical
Priority: low
Component: HAL
AssignedTo: unassigned@bugs.ecos.sourceware.org
ReportedBy: willw@carallon.com
CC: ecos-bugs@ecos.sourceware.org
Class: Advice Request
Created an attachment (id=1249)
--> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1249)
Patch that fixes the issue
I am using an at91sam7x512, using a recent checkout from CVS (No more than 2
months old) and the code confidence tools.
When compiling the code in thumb mode with optimisations I am seeing a data
abort exception on the return from an ISR (The first instruction in vectors.S
after returning from the ISR). I am reproduing this issue using the adc driver
and it is the ISR at91_adc_isr that is triggering the problem.
We tracked this down to be a problem with which mode arm/thumb the processor is
in. When the processor jumps to the IRQ handler in vectors.S it is in arm mode
and when it jumps to the isr it changes to thumb mode using the bx instruction
(vectors.S:934). The ISR then executes in thumb mode and returns using the
address set in the link register. However the value in the link register does
not have the last bit set and so the processor changes back to arm mode.
However the code in vectors.S at the link register address is thumb code
(vectors.S:939). When the two thumb instructions are instead treat as an arm
instruction it produces the data abort we are seeing. The reason it works in a
non optimised build and for all the other ISR's is that the arm instruction
that results from the two thumb instructions has a condition that the N bit is
not set in the cpsr. In the optimised case at91_adc_isr returns with the N bit
set in the cpsr but for other isr's and the non-optimised case this doesn't
happen. The processor then doesn't execute the bogus instruction and you end up
where the two thumb instructions were trying to get you to anyway correctly in
arm mode.
To check this analysis is correct we have applied the attached patch and that
fixes the issue by ensuring the lowest bit is set in the link register. It then
returns from the isr still in thumb mode and jumps back to arm mode as
intended.
I'm not certain this is the correct fix, or even if this is some toolchain
issue. Presumably if the isr returned by some other mechanism than a bx
instruction then the processor would still be in thumb mode? If we know the isr
will always be able to change mode on return then there is no need for the two
thumb instructions at all.
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.