This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001238] New: Thumb mode return from ISR causes undefinedbehaviour


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]