• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 1610 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.

CCS/TM4C123GH6PM: Assembly Language Project: Debugger does not start in Thumb State

Raymond Mayer
Prodigy 80 points
Part Number: TM4C123GH6PM
Other Parts Discussed in Thread: EK-TM4C123GXL

Tool/software: Code Composer Studio

The following assembly language project was created using CCS v7 and TI v16.9.1.LTS (v16.9.3.LTS was also tested with the same results):

The .asm file contains:

    .global
    .text
main:
    nop
    movw    r0, #0x1234
    b       main
    .end

The .cmd file contains:

MEMORY
{
FLASH (RX) : origin = 0x00000000, length = 0x00040000
SRAM (RWX) : origin = 0x20000000, length = 0x00008000
}

SECTIONS
{
.text : > FLASH
}

It appears that the CCS debugger launches debug mode with the T bit in the xPSR cleared:

In thumb mode (the Cortex-M4 can only execute in thumb mode), the encoded instructions are:

    .global
    .text
main:
    nop                    BF00
    movw    r0, #0x1234    F2412034
    b       main
    .end

When single-stepping, they are not interpreted properly and exception 11 (0x0B = SVCall) is generated with the PC assigned a value of 0xFFFFFFFE

If the xPSR is modifed before single-stepping from 0x00000000 to 0x01000000 (setting the T bit), then execution is normal. It was observed that the T bit does get set after the exception is generated and if the PC is manually assigned a value of 0, the debugger appears to operate normally.

This sequence does not occur on the MacOS with CCS v7 and TI v16.9.1.LTS

Any assistance with this would be appreciated.

  • 0
    Prodigy 80 points
    I should also mention that this is using the EK-TM4C123GXL Tiva C Series LaunchPad.
  • 0
    TI__Guru**** 191886 points
    Hi Raymond,
    Not sure if this is your entire program. The first entry in the vector table is for the stack pointer and the second entry is for the reset vector. But you have a NOP at address 0x0 as if 0xBF00 is the stack pointer and 0xF2412034 as the reset vector for the CPU to jump to after reset.
  • 0 in reply to Charles Tsai
    Prodigy 80 points
    Thank you Charles - Yes that is the problem:

    After reset, the program counter is loaded with 0xF2412034 as you pointed out even though the debugger uses "main" as the entry point (loaded later). Since the address 0xF2412034 has the least significant bit cleared, the T bit in xPSR is also cleared.

    Simply placing the following interrupt vector table will allow it to work. Even though the symbol "main" is on an even boundary, 1 is added to the address to force the Cortex-M processor into Thumb state.

    .sect ".intvecs"
    .long 0x20000000
    .long main <-- a value of 1 is automatically added to this address by the assembler

    Reference: "ARMv7-M Architecture Reference Manual" section B1.4.2, page B1-574, and Charles Tsai

    Thanks again Charles!
  • 0 in reply to Raymond Mayer
    TI__Guru**** 191886 points
    Glad your problem is solved!