EK-TM4C123GXL: Softreset by Application Interrupt and Reset Control

Hi Dashi,
What program were you running when the hanging occurred? When it hangs is the debugger still able to connect to the MCU? If you have loaded different programs will you see the same hanging?

The Reset will proceeds if I interrupt to debug it and issue the continue command. When in debug, it stops at either one of the two positions: The reset vector, or another address 0x01..... I can get the exact address if it is needed.

Hi Dashi,
I guess you haven't answered my prior questions. If the code stops at the reset vector then isn't that what you expected as you issued a software reset? If the address is 0x01xxxxxx then it is executing TivaWare library code. If you single step does the program counter continue to change?

The program is a test by myself. It can be downloaded from by the command "git clone"

If the reset operation got stuck, I think it will stop there forever, since if the reset succeeds, it will restart in a blink of eyes.  But when it hangs, I can interrupt it using GNU gdb, it will restart when I issue the continue command.

I guess the 0x01xxx is at the ROM function "ROM_SysCtlReset", so I copy the reset codes into my program:

static inline void tm4c_reset(void)
{
    uint32_t v;

    v = HWREG(NVIC_APINT) & 0x0ffff;
    HWREG(NVIC_APINT) = v|0x05fa0000|NVIC_APINT_SYSRESETREQ;
    while (1)
        ;
}

If the board will not reset by softreset after power on, it will always hang at softreset. A gdb session is as below:

(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
0x01001024 in ?? ()
(gdb) bt
#0  0x01001024 in ?? ()
(gdb) c
Continuing.
^C
Program stopped.
0x00000288 in ResetISR ()
(gdb) c
Continuing.

(gdb) c
Continuing.
^C
Program stopped.
0x00000288 in ResetISR ()
(gdb) info reg
r0             0x0    0
r1             0x0    0
r2             0x0    0
r3             0x0    0
r4             0x0    0
r5             0x0    0
r6             0x0    0
r7             0x0    0
r8             0x0    0
r9             0x0    0
r10            0x0    0
r11            0x0    0
r12            0x0    0
sp             0x20000800    0x20000800 <dmacr>
lr             0xffffffff    -1
pc             0x288    0x288 <ResetISR>
xpsr           0x1000000    16777216
(gdb)

Hi Dashi,
You just mentioned you are using gdb as your debugger, correct? I'm not familiar with gdb. Have you try to use CCS to debug the same program? Is is possible that in gdb there is a default breakpt setup at the reset vector?

BTW, can you attach the project here?

Hi Charles,

I don't think the debugger is relevant. I only start the debugger to interrupt into the program if the softreset hangs in the first place. The softreset succeeds sometimes. If it succeeds after power up, it will always succeed until the power is unplugged.

tm4c-master.zip

Hi Dashi,
I'm out of office until Thursday. I can't look into your project until I come back. I only have a tablet device with me right now.

Was the debugger connected to the MCU when you generate the software reset? Can you try to run your code when the debugger is unconnected to the MCU?

Can you try either of the below to generate software reset, will it make a difference?

1. Call SysCtlReset() API.
2. HWREG(NVIC_APINT) = NVIC_APINT_VECTKEY | NVIC_APINT_SYSRESETREQ;

Hi Charles,

I suspect that the issue is related to the Linux usb-serial-simple driver. The driver may write something to the ICDI when it is attached. I'll write a reply if I can confirm it.