• State
  • Locked Locked
  • Replies 14 replies
  • Subscribers 34 subscribers
  • Views 1697 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.

How to trigger "usage fault handler" manually?

Nicolas Göddel
Intellectual 795 points

Other Parts Discussed in Thread: STRIKE

Hi there,

how can I trigger the "usage fault handler" manually? It is located at position 6 in the g_pfnVectors array in startup_ccs.cpp and initialised with the "IntDefaultHandler". I want to be able to call that trigger from every position in my code.


I am using the Tiva C Connected Launchpad TM4C1294XL with Code Composer Studio and the latest TI Compiler.

  • 0
    Guru 27665 points
    Umm, that strikes me as a bad idea. What are you trying to do that would make that seem desirable?

    Robert
  • 0
    TI__Guru**** 244440 points
    Hello Nicolas

    Why do you want to trigger a fault handler?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 795 points

    For example if someone calls a class constructor with wrong parameters. Because it is too complicated to throw a C++ exception I want to trigger an interrupt instead. An other idea would be to use ASSERT like in other function in the tilib.

  • 0 in reply to Nicolas Göddel
    TI__Guru**** 244440 points
    Hello Nicolas

    From your previous thread

    e2e.ti.com/.../1650231

    The good question would be how the code does this at runtime?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 795 points
    I thought it should be no problem to call a interrupt function at runtime.
    What about to simply call "g_pfnVectors[6]()"?
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Hi Amit,

    If poster (must) do this - wouldn't an "SWI" (software interrupt) prove far easier & much less disruptive?

    As I recall - such may be called from his desired, (near) "every position" w/in his code...

    And - a hidden fringe benefit - such SWI escapes the (usual) requirement for an iret @ interrupt's end...

  • 0 in reply to cb1
    TI__Guru**** 244440 points
    Hello cb1,

    Yes, that is correct. A SWI would be more manageable than a fault.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 795 points
    I have no experiences with SWI. How can I do this?
  • 0 in reply to cb1
    Guru 10570 points

    I would certainly think so. The C++ exception mechanism is almost certainly simpler though, it had built-in cleanup mechanisms Nicolas would need to duplicate in some fashion.

    Robert

  • 0 in reply to Nicolas Göddel
    Guru 10570 points
    That vector is reserved for processor exceptions like invalid instructions. You really do not want to repurpose.

    Also it's not an interrupt but an exception (all interrupts are exceptions, not all exceptions are interrupts). You really have to read the fine print on non-interrupt exceptions, the restrictions, call and return can be quite different from an interrupt exception.

    Robert
  • 0 in reply to Nicolas Göddel
    Guru 10570 points
    You can look for SVC, IIRC swi is from an earlier core but maybe both exist. I do think though, that reinventing the wheel will not serve you well without a more compelling motive.

    Robert
  • 0 in reply to Nicolas Göddel
    Guru 47900 points
    As I recall - the SWI is detailed w/in the, "Interrupt Section" of your MCU manual. After digesting - if still unclear - I can provide a sample usage which my firm has used w/great success for the past 5+ years in an on-going, volume application...
  • 0 in reply to cb1
    Guru 10570 points
    Care to share why you used an swi cb1? AFAICT function pointers, with a few exceptions will work as well or better than an swi.

    The exceptions I can think of are

    Privilege raising. SVC does this and IIRC so does swi on ARM7 cores
    Stack switching. Only on some processors. ARM7 cores did this IIRC but I don't think the Cortex cores do. Could be done in a function but the swi might be simpler sometimes.

    Other than that I think function pointers are equivalent or superior.

    Robert
  • 0 in reply to Robert Adsett72
    Guru 47900 points

    Recall Robert that this was 5 years past.   And we were sufficiently impressed that we devised code which employed (two) SWI - we did this w/a Cortex M3 (later migrated to an M4) - and in conjunction w/this vendor's, well versed, FAE.   (I made no claim to "inventing" such - yet we very much sought to exploit this method - and experimentation proved it out.)

    I'll have to pull & review our project notes - but my recall is that we achieved improved performance, program robustness & simplicity - all via the use of SWI over other methods.  I do recall that we invoked the SWI from a known/critical program interrupt - and as I noted earlier - when the SWI completed - it returned (automatically - {w/o iret}) to that triggering interrupt.

    Such SWI usage did strike us as "unusual" - again this was (this) vendor's recommendation - and I'm certain that our overall gains (as measured & confirmed) outweighed those achieved via more conventional methods.  

    I kinow you to be a fan of "experimentation" - might your "doubt" justify a "Robert experiment" - to confirm your belief - which is outside of vendor's FAE & cb1 firm's findings?    Might it be that SWI is unique enough to fall outside of your recent usage & exploitation - that was our case - we've not looked back...