ARM 946E-S Abort failure (derived from csb337 bsp)

[x ray]

Hi, Gds

It is little strange that spsr = 0xD1 =0x11010001
the last 5bit 10001 means you are in FIQ mode.
However, I remembered that the ARM bsp do not fully implement FIQ handler.

BTW, I have taken a quick look in ARM946E spec. There is another issue
you should note, in chap 2.2.1 data abort mode. It seems that ARM9E-S
differ form ARM7TDMI in the Data abort model.

2008/3/25, gds <gds at chartertn.net>:
> I have been trying to just run the simple_main and/or hello_world
>  examples. My console port (polled in/out) is coded, connected and seems
>  to work so I can see some output. Also, am able to debug with
>  arm-rtems4.8-insight debugger using a jtag debugger (Macraigor mpDemon
>  with built-in gdb server).
>
>  Occasionally I am able to get all the way to main but more often I see
>  an abort failure somewhere along the line. Seem rather flaky and
>  inconsistent and not repeatable.
>
>  Here is what I often see printed usually before main or after exiting
>  main():
>
>  INSN_LDM1
>  data_abort at address 0x847C, instruction: 0xE8916FF4,   spsr = 0xD1
>  active thread thread 0x0A010001
>  Previous sp=0x000179EC lr=0x00008488 and actual cpsr=600000D7
>   0x00015BFC 0x00020F58 0x00000013 0x00015D14 0x600000D1 0x00000000
>   0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
>   0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
>   0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
>   0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
>   0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
>   0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
>   0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
>
>  The code at address 0x847c is in _Context_switch and looks like this
>  (from arm-rtems4.8-objdump):
>
>  00008474 <_CPU_Context_switch>:
>      8474:       e10f2000        mrs     r2, CPSR
>      8478:       e8806ff4        stm     r0, {r2, r4, r5, r6, r7, r8,
>  r9, sl, fp, sp, lr}
>
>  0000847c <_restore>:
>      847c:       e8916ff4        ldm     r1, {r2, r4, r5, r6, r7, r8,
>  r9, sl, fp, sp, lr}
>      8480:       e129f002        msr     CPSR_fc, r2
>      8484:       e1a0f00e        mov     pc, lr
>
>  00008488 <_CPU_Context_restore>:
>      8488:       e1a01000        mov     r1, r0
>      848c:       eafffffa        b       847c <_restore>
>
>  However, if I step through this code it does not fail. Also, if I set a
>  breakpoint at 0x847c it never hits it before printing the exception
>  message indicting "data abort".  I think "data abort" means I am
>  accessing data outside of my ram space or possibly accessing an
>  instruction that is not on a 32-bit word boundary.
>
>  I also see other failures.  Sometimes I see invalid SWI (software
>  interrupt) detected. However, I think this code doubles for detecting
>  undefined instructions, which may be what triggers it. (I don't see any
>  software interrupts used in rtems, at least with ARM.)
>
>  Any suggestions on what I should be looking for here to debug this? I
>  think I should be able to run to main and exit main with no errors printed.
>
>  Thanks,
>  -gene
>
>  _______________________________________________
>  rtems-users mailing list
>  rtems-users at rtems.com
>  http://rtems.rtems.org/mailman/listinfo/rtems-users
>


-- 
Thanks & Best Regards!

Ray, Xu