[Zaire]

Dear All

I have find a strange behavior on cortexA9/R4,

My mode data code as below

0x0 0x8100F3EF MRS R1,CPSR (current CPSR value is 0x1F3)

However when I execute the line, the value in R1 is 0x1D3, Isn't it should be 0x1F3?

Is it a chip bug? or there is some other reason?

If anyone knows the answer, please let me know.

[ttfn]

Bit 5 is the T bit (ARM or Thumb state). The value you're getting back implies you are in fact in ARM state. How do you know what the value should be? Are you using a debugger?

[sim]

The T-bit is not readable via MRS. The least significant byte of the CPSR is masked with 0xDF when read.

hth
s.

[Zaire]

 ttfn, on 28 July 2011 - 11:46 AM, said:

Bit 5 is the T bit (ARM or Thumb state). The value you're getting back implies you are in fact in ARM state. How do you know what the value should be? Are you using a debugger?

I'm using a debugger

data in 0x0700000C is MRS r1,cpsr[0x8100F3EF] , start program at 0x07000002 [thumb mode] and stop at Bp 0x0700001A, but the R1 value is not 0x1F3, it shown as 0x1D3

 MRS_Before.jpg (207.04K)
Number of downloads: 4

 MRS_After.jpg (207.75K)
Number of downloads: 4

[Christophe31]

Hi,

Answer is in DDI0406B (ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition), §B1.3.3 :
The execution state bits are the IT[7:0], J, E, and T bits. In exception modes you can read or write these bits
in the current SPSR.
In the CPSR, unless the processor is in Debug state:
• The execution state bits, other than the E bit, are RAZ when read by an MRS instruction.

Regards

Christophe

[Christophe31]

Hi again,

I think the solution is with software interrupt (also called "system call") :
- add a dedicated entry in your intvecs table :

b _c_int00
undefEntry
b undefEntry
svcEntry
b ISR_SWI ; SOFTWARE INTERRUPT
...

- that you can call with :
svc 0x01


- and which contains something like :
ISR_SWI
; here, cpsr is copied into spsr_svc
mrs r1,spsr
movs pc, lr ; Return

Regards

Christophe