• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 952 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

During Simulation always runs in undefEntry Interrupt

Constantin Wiesener
Intellectual 540 points
Other Parts Discussed in Thread: HALCOGEN

I've got a small example which I ve debuged using the jlink debugger. Now I wanted to test the TI simulator. But it always runs into a undefined exception undefEntry?

tmstestCPP.zip
  • 0
    TI__Guru 68950 points

    The TI Cortex R4 simulator doesn't support the floating point instructions.   This is likely what you're running into.

    There isn't a simulator alternative, we currently do not offer a Cortex R4F simulator. The best alternative is one of the low cost hardware platforms.  

  • 0 in reply to Anthony F. Seely
    Intellectual 540 points

    So how can I avoid floating point instructions using halcogen. Or better said, how can I disable the FPU using halcogen.

    I mean I can tell the compiler to not use floating point support. And comment out all instructions of the fpu registers,but I am still running in the same problem.

    Are you planning to improve the simulator so that it is able to deal also with MPU and FPU. I mean the XDS interface are so slow, that you are spending half the day downloading the binary.


    Kind regards.

    a.

  • 0 in reply to Constantin Wiesener
    TI__Guru 68950 points

    abeat,

    There isn't any switch that I'm aware of in HalCoGen to not enable the FPU.

    So you would need to manually comment out the FPU instructions.  But if you did this and you still get an undefined instruction exception then the issue may be something else other than floating point.

    Do you know how to trace back to the instruction that triggered the undefined instruction exception?  It might be worth doing this in order to confirm it is FPU.   In my mind that is most likely the case but it could be something else.   Or there could be another file with FPU instructions that you missed commenting out - either way it probably makes sense as a next step to track this down.   [assuming you are willing to go down the 'fix manually' path].

    I don't think we have plans enhance the simulator - the focus has been on getting low cost hardware out.

    If you need more speed on the XDS emulator:

      a) make sure you are using CCSv5 as it is significantly faster with XDS100v2

      b) try changing the flash option to only erase the flash sectors that are required for your application.   this will shave a lot of time off the program/erase operation for small programs.

      c) consider upgrading to a full CCS license w. XDS200 or better emulator.  or look at an alternative like J-LINK.  These are much faster than the XDS100v2 although they cost more.

     

  • 0 in reply to Anthony F. Seely
    Intellectual 540 points

    How can I trace back to the instruction that triggered the undefined instruction exception?

  • 0 in reply to Constantin Wiesener
    TI__Guru 68950 points

    Hi abeat,

    There is some detailed information in the Cortex-R4 and Cortex-R4F Technical Reference Manual on ARM's website, you want sections 2.8.1 and 2.8.6 of revision r1p3.  

    I'll try to paraphrase though with a little more specifics - but if I missed something you might refer to the above references....

    While you are stopped at the undefined instruction vector, inspect SPSR_UND and R14_UND.

    SPSR_UND bit 5 will tell you if the exception was from ARM (0) or THUMB (1) mode.

    The address of the undefined instruction is then either R14_UND + 4 (if ARM) or R14_UND + 2 (if Thumb).

    After making the adjustment of +4 or +2 as appropriate, you can enter that address into the disassembly window of the IDE to find out what the instruction was. 

    In reading 2.8.6 I just noticed that in addition to the FPU instructions, an integer divide by zero might generate an undefined exception.  And of course an invalid opcode would do this too;  for example if you branched into uninitialized RAM somehow you might get this exception.