• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 3231 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.

GNU examples for EK-TM4C123GXL fail to start unless debugger connected

Chester Gillon
Guru 92251 points
Other Parts Discussed in Thread: EK-TM4C123GXL, SYSBIOS

Using tirtos_tivac_2_00_01_23 installed in CCS 6.0.0.00190 to run examples on a EK-TM4C123GXL launchpad, found that:

1) The "UART Echo" and "GPIO interrupt" TI target examples run when downloaded using the CCS debugger. They also successfully run if the CCS debugger is not connected.

2) The "UART Echo" and "GPIO interrupt" GNU target examples run when downloaded using the CCS debugger. However, they fail to run if the CCS debugger is not connected. i.e. the sequence:

- Download the examples from the CCS debugger and they function correctly.

- Terminate the CCS debug session, and they continue to function.

- Press the reset button on the EK-TM4C123GXL launchpad and the programs fail to start with no sign of life. There is no output on the serial connection from the "UART Echo" example and neither example lights the led on the launchpad.

Is this the expected behaviour for the GNU target TI-RTOS examples?

  • 0
    TI__Mastermind 45025 points

    Chester Gillon said:

    - Download the examples from the CCS debugger and they function correctly.

    - Terminate the CCS debug session, and they continue to function.

    Are you selecting "run" when you do this?  Or "free run"?

    If not "free run", can you try again by selecting 'run -> free run' in CCS?  Then stop the debug session?

    Steve

  • 0 in reply to Steven Connell
    Guru 92251 points

    Steven Connell said:
    Are you selecting "run" when you do this?  Or "free run"?

    If not "free run", can you try again by selecting 'run -> free run' in CCS?  Then stop the debug session?

    I was using Resume (F8) with no breakpoints set prior to stopping the debug session.

    Using "run -> free run" before stopping the debug session didn't change the behavior.

    I also found that after using CCS to download the program (into flash):

    1) If the Tiva launchpad is power cycled when a TI target example is in flash, the example starts to execute from power-on.

    2).If the Tiva launchpad is power cycled when a GNU target example is in flash, the example shows no sign of activity after the power cycle.

  • 0 in reply to Chester Gillon
    Guru 92251 points

    With the  "GPIO interrupt" GNU target example in flash, after power-cycling the Tiva Launchpad attached the CCS debugger to the target to see what state it was in.

    The  "UART Echo" and "GPIO interrupt" examples (and maybe others) make use of SysMin System Provider to print to the host debugger console.

    While I don't fully understand the sequence of the failure, I think the problem is that the GNU target host I/O uses a BKPT #171 instruction in the do_AngelSWI inline function in the run time library to signal to the host that host I/O is needed. The ARM Cortex-M4 Devices Generic User Guide says "The BKPT instruction causes the processor to enter Debug state", and thus I think the target will halt if no debugger is attached when host I/O is attempted.

    Whereas the TI target host I/O requires the debugger to set a breakpoint on specific CIO functions, and thus if there is no debugger attached the target won't halt when host I/O is attempted.

  • 0 in reply to Chester Gillon
    TI__Mastermind 45025 points

    Chester,

    Ok, these are interesting results you've found.  I'll get this set up and see if I can reproduce this tomorrow.

    Steve

  • 0
    TI__Mastermind 45025 points

    Chester,

    Chester Gillon said:

    2) The "UART Echo" and "GPIO interrupt" GNU target examples run when downloaded using the CCS debugger. However, they fail to run if the CCS debugger is not connected. i.e. the sequence:

    - Download the examples from the CCS debugger and they function correctly.

    - Terminate the CCS debug session, and they continue to function.

    - Press the reset button on the EK-TM4C123GXL launchpad and the programs fail to start with no sign of life.

    I was able to reproduce this for the GPIO example on a slightly different hardware platform, the Tiva C1294NCPDT launchpad.

    When running the GPIO example built for TI targets, it could run successfully on the initial run (CCS debug session active), continued to run after halting the debug session, and again ran/restared when I hit the h/w reset button on the board itself (I was still able to blink the LEDs in all of these cases).

    And for GCC I saw the same (as you reported).  All was good when repeating those steps except for when I hit the reset button - the example didn't seem to restart in that case.

    I'll ask some folks who are more familiar with the example and see if they have any ideas about this behavior.

    Steve

  • 0 in reply to Steven Connell
    TI__Mastermind 45025 points

    Chester,

    I just wanted to give you an update.  We are still debugging this issue and will get back to you soon.

    Have a great weekend.

    Steve

  • 0 in reply to Chester Gillon
    TI__Mastermind 21645 points

    Hi Chester,

    Chester Gillon said:

    While I don't fully understand the sequence of the failure, I think the problem is that the GNU target host I/O uses a BKPT #171 instruction in the do_AngelSWI inline function in the run time library to signal to the host that host I/O is needed. The ARM Cortex-M4 Devices Generic User Guide says "The BKPT instruction causes the processor to enter Debug state", and thus I think the target will halt if no debugger is attached when host I/O is attempted.

    That is correct. The UART Echo example is built with semi-hosting enabled and will not work as expected if the debugger is disconnected.

    Semi-hosting is implemented using breakpoints in Cortex-M3/M4 targets. If the debugger is connected, it knows how to process the semihosting breakpoint and continue execution. However, if the debugger is disconnected and the board is reset, the app will not be able to continue execution at the breakpoint.

    The solution to your problem is to replace the librdimon (semi-hosting) library with libnosys library and remove the useModule for "ti.sysbios.rts.gnu.SemiHostSupport" module from the example's *.cfg file.

    I think this info needs to be in the readme for the example. I will file a bug to get it added.


    Best,

    Ashish

    Screenshots for the changes required:

    Replace "rdimon" with "nosys":

    Remove useModule for SemiHostSupport module from UARTEcho's *.cfg file:

  • 0 in reply to Ashish Kapania
    Guru 92251 points

    Ashish Kapania said:
    The solution to your problem is to replace the librdimon (semi-hosting) library with libnosys library and remove the useModule for "ti.sysbios.rts.gnu.SemiHostSupport" module from the example's *.cfg file.

    Thank you for the explanation and solution. I confirm that the solution works, and allows the examples to run without the debugger connected.