Unexpected trap(0 x4) ... fp disabled

[Jiri Gaisler]

Well, 0x40006710 is a NOP so either the RTEMS message did not print
the correct address or your program might have overwritten the
address 0x40006710 with some random value. The easiest way to
debug this is to load the binary using command-line grmon, and
then just print the history when grmon break on the trap:

load app.exe
run
ins 20


You might also want to check stack sizes etc. Auto-generated code
tends to be heavy on memory and stack ...

Jiri.

Gardner, Michael T wrote:
> Jiri,
>  
> Here is the disassembled code at the 0x40006710 address:
>  
> 400066e8:       10 80 00 10      b  40006728
> <_ZN16GaislerInterfaceD1Ev+0xc4>
> 400066ec:       01 00 00 00      nop
> 400066f0:       f0 27 bf f0      st  %i0, [ %fp + -16 ]
> 400066f4:       82 10 00 19      mov  %i1, %g1
> 400066f8:       a2 10 00 01      mov  %g1, %l1
> 400066fc:       e0 07 bf f0      ld  [ %fp + -16 ], %l0
> 40006700:       c2 07 a0 44      ld  [ %fp + 0x44 ], %g1
> 40006704:       c2 27 bf f4      st  %g1, [ %fp + -12 ]
> 40006708:       d0 07 bf f4      ld  [ %fp + -12 ], %o0
> 4000670c:       40 00 00 8d      call  40006940 <_ZN17HardwareInterfaceD2Ev>
> 40006710:       01 00 00 00      nop
> 40006714:       e0 27 bf f0      st  %l0, [ %fp + -16 ]
> 40006718:       82 10 00 11      mov  %l1, %g1
> 4000671c:       d0 07 bf f0      ld  [ %fp + -16 ], %o0
> 40006720:       40 01 84 73      call  400678ec <_Unwind_Resume>
> 40006724:       01 00 00 00      nop
> 40006728:       d0 07 a0 44      ld  [ %fp + 0x44 ], %o0
> 4000672c:       40 01 5d 18      call  4005db8c <_ZdlPv>
> 40006730:       01 00 00 00      nop
> 40006734:       81 e8 00 00      restore
> 40006738:       81 c3 e0 08      retl
> 4000673c:       01 00 00 00      nop
>  
> The code is autogenerated from our model driven development tool called
> Rhapsody.  I have configured the eclipse project to call the
> auto-generated makefile, which is probably a little different that
> building the project using the eclipse plug-in.  I have included in the
> makefile the –msoft-float option but this has not made any difference. 
> The code still crashes.  BTW, there is another developer using
> essentially the same process to generate and build his code with
> Rhapsody.  He also compiles with the Rhapsody makefile.  His test
> program worked but mine failed.  The telling difference between the two
> programs is that his does not use any floating point variables where
> mine does.  As a test, I included a simple declaration of a double and
> printed out the value.  This two line change now causes his program to
> crash with the same error.  So the error really is tied to floating
> point operations.
>  
>  
> Michael T. Gardner
> Sandia National Labs
> mtgardn at sandia.gov
> 505-844-1299
>  
>  
>  
> 
> 
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users