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.

TM4C1230H6PM: Accessing from the debug port

Part Number: TM4C1230H6PM

Tool/software:

Hi,

I am considering accessing it from the debug port of the TM4C1230H6PM.

-Is the register configuration of the debug port of the TM4C1230H6PM the standard configuration for the ARM Cortex-M4F core? Or is it a custom configuration?

-I don't want the CPU to run when I turn on the power. Is it possible to put the CPU into a halted state by setting the C_HALT bit of the Debug Halting Control and Status Register to 1 while keeping the TM4C1230H6PM pin 38: /RST pin = LOW?

-And in this state, if I change the TM4C1230H6PM pin 38: /RST pin from LOW to HIGH, will the CPU halted state be maintained?

-After that, will it be possible to access the Flash Memory Registers from the debug port?

Regards,

Toru

  • -Is the register configuration of the debug port of the TM4C1230H6PM the standard configuration for the ARM Cortex-M4F core? Or is it a custom configuration?

    Hi Toru-san,

      TM4C123 uses the Cortex-M4F core. You can access any Debug Registers inside the core through the DAP interface.

    -I don't want the CPU to run when I turn on the power.

    The moment you turn on the power to the device, the device is going to start running unless you force it to stay in reset. 

    Is it possible to put the CPU into a halted state by setting the C_HALT bit of the Debug Halting Control and Status Register to 1 while keeping the TM4C1230H6PM pin 38: /RST pin = LOW?

    Yes, if you hold the /RST pin low then the processor is in reset state. You can halt the processor by scanning in the C_HALT bit to the Debug Halting register. If you don't hold the processor in reset, the processor will start running. By the time you scan in the C_HALT bit, the processor has already run the application.

    -After that, will it be possible to access the Flash Memory Registers from the debug port?

    Yes, I don't see why not. 

  • Hi, Charles-san

    Thank you for answering my question.

    I would like to confirm just to be sure.

    As you answered in the previous question that it is possible,
    I would like to set the C_HALT bit in the Debug Halt Control and Status Register to 1 while keeping the pin 38: /RST pin = LOW, and put the CPU in a halted state.

    Then, if I change the pin 38: /RST pin from LOW to HIGH, will the CPU halted state be maintained?

    Regards,

    Toru

  • Hi Toru-san,

     Sorry, my bad. Reading the datasheet again, it looks like an /RST low will reset the Arm core regardless the reset pin is configured for simulated POR or System Reset.

  • Hi, Charles-san

    >it looks like an /RST low will reset the Arm core regardless the reset pin is configured for simulated POR or System Reset.

    Thank you for your confirmation and reply.

    - As I expect, am I correct in understanding that if the /RST pin is held LOW, the core will be kept in reset state and will not operate?

    - And if I set the C_HALT bit to 1 and keep the CPU stopped, will the CPU be kept stopped even if I change the /RST pin from LOW to HIGH?

    Regards,

    Toru

  • Hi Toru-san,

    - As I expect, am I correct in understanding that if the /RST pin is held LOW, the core will be kept in reset state and will not operate?

    That is correct. As long as /RST is active low, the core is in reset state.

    - And if I set the C_HALT bit to 1 and keep the CPU stopped, will the CPU be kept stopped even if I change the /RST pin from LOW to HIGH?

    I'm not clear here. Suppose the CPU is out of reset and you set the C_HALT to 1, this will request to halt the processor. If you assert /RST low then it will clear the C_HALT bit to 0. 

    https://developer.arm.com/documentation/ddi0419/c/Debug-Architecture/ARMv6-M-Debug/Debug-register-support-in-the-SCS/Debug-Halting-Control-and-Status-Register--DHCSR?lang=en

  • Hi, Charles-san

    Thank you for your response.

    Let me check the details of the answers I have received so far.

    - If the /RST pin is asserted from HIGH to LOW while the C_HALT bit is set to 1, does the C_HALT bit clear to 0?

    - If the /RST pin is released from LOW to HIGH while the C_HALT bit is set to 1, does the C_HALT bit stay 1?

    - If power is applied between VDD and GND while the /RST pin is held LOW, will the CPU remain halted and not run?

    - Is it possible to set the C_HALT bit to 1 while the /RST pin is held LOW?

    Regards,

    Toru

  • Hi,

    I think you can try out on a LaunchPad for experiment. On a LaunchPad, I first set up some breakpoints on a program. if I press the nRST pin then the debugger will be disconnected. I will have to reconnect with the target. Once connected, the breakpoints that I setup earlier were lost. This means a nRST pin will clear the Arm core debug logic. 

    - If the /RST pin is asserted from HIGH to LOW while the C_HALT bit is set to 1, does the C_HALT bit clear to 0?

    Yes. Refer to my experiment above. 

    - If the /RST pin is released from LOW to HIGH while the C_HALT bit is set to 1, does the C_HALT bit stay 1?

    This cannot be possible to begin with. While the nRST is active, the debug logic including the C_HALT bit will be reset to 0.

    - If power is applied between VDD and GND while the /RST pin is held LOW, will the CPU remain halted and not run?

    If the nRST pin is held low then the device is in reset state. It will not run. 

    - Is it possible to set the C_HALT bit to 1 while the /RST pin is held LOW?

    No.