• Locked Locked
  • Replies 6 replies
  • Subscribers 119 subscribers
  • Views 5099 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Semihosting with Cortex-A5 and T32

Paras (O) Agarwal
Note: This was originally posted on 9th August 2013 at http://forums.arm.com

With Semihosting enabled, after seeing SVC 0xAB (for SYS_WRITE; R0=5) by Cortex-A5, how the message is passed to the DAP/debugger? In the code, I'm not handling SVC exception. Even I'm not able to do a 'vector catch' here.

Prints are coming on T32.
  • Note: This was originally posted on 12th August 2013 at http://forums.arm.com


    Can you explain more about what you are trying to do, what you want to happen and what is happening?  In particular I can't tell if you are having trouble with a different debugger (if so which one) or when using no debugger.

    When a debugger that does semihosting is attached (and correctly configured) it will place a vector catch or breakpoint on the SVC vector.  When the target does a semihosting operation the debugger will stop the target, do the operation and resume the target.


    I'm using Lauterbach(T32) debugger and am trying to understand the functionality of how a message is passed from ARM->DAP->JTAG.   e.g. a printf("hello")
    So, the current understanding is:
    1. In printf ARM library, SYS_WRITE is used
    2. SYS_WRITE modifies r0 and r1 followed by SVC 0xAB instruction
    3. After seeing SVC 0xAB, vector catch is used by the debugger and some arm library file uses DBGDTRTX register to write the bytes to the DAP/host registers
    4. Finally  T32 application, through JTAG, read these bytes

    Is this understanding current?
  • Note: This was originally posted on 12th August 2013 at http://forums.arm.com

    OK, understood now.

    Can you also point to the library file which writes into DBGDTRTX register?

    Thanks
  • Arm Employee Badge
    Note: This was originally posted on 12th August 2013 at http://forums.arm.com

    Broadly - yes.

    The debugger also has to perform a pseudo exception return at the end, as the application is not expected to handle the SVC.
  • Arm Employee Badge
    Note: This was originally posted on 12th August 2013 at http://forums.arm.com


    With Semihosting enabled, after seeing SVC 0xAB (for SYS_WRITE; R0=5) by Cortex-A5, how the message is passed to the DAP/debugger? In the code, I'm not handling SVC exception. Even I'm not able to do a 'vector catch' here.

    Prints are coming on T32.


    Can you explain more about what you are trying to do, what you want to happen and what is happening?  In particular I can't tell if you are having trouble with a different debugger (if so which one) or when using no debugger.

    When a debugger that does semihosting is attached (and correctly configured) it will place a vector catch or breakpoint on the SVC vector.  When the target does a semihosting operation the debugger will stop the target, do the operation and resume the target.
  • Arm Employee Badge
    Note: This was originally posted on 13th August 2013 at http://forums.arm.com

    I don't know the details, but there's no need for library code to write DBGDTRTX.  When the target stops on the vector catch/breakpoint the debugger can determine that it has stopped because of a semihosting SVC and then read/write the registers and memory in the usual debugger way.  Then the debugger can simulate returning from the SVC and resume the target.
  • Note: This was originally posted on 12th August 2013 at http://forums.arm.com


    With Semihosting enabled, after seeing SVC 0xAB (for SYS_WRITE; R0=5) by Cortex-A5, how the message is passed to the DAP/debugger? In the code, I'm not handling SVC exception. Even I'm not able to do a 'vector catch' here.

    Prints are coming on T32.



    Please go through the following link. it might help you to understand semihosting operations
    http://infocenter.arm.com/help/topic/com.arm.doc.dui0471i/DUI0471I_developing_for_arm_processors.pdf
    The function angel_SWIreason_EnterSVC Sets the processor to Supervisor mode and disables all interrupts by setting both interrupt mask
    bits in the new CPSR.
    SVC 0xAB In ARM state and Thumb state, excluding ARMv6-M and ARMv7-M. This
    behavior is not guaranteed on all debug targets from ARM or from third parties. I am not sure if it is debug hardware (Trace 32, DSTREAM) dependent.
    The SVC number indicates to the debug agent that the SVC instruction is a semihosting request