• State
  • Locked Locked
  • Replies 20 replies
  • Subscribers 33 subscribers
  • Views 4780 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.

Tiva-C debug errors

abonyi zoltán
Prodigy 100 points

Other Parts Discussed in Thread: TM4C123GH6PM, SW-DRL, EK-TM4C123GXL

Hi,

I am using a Tiva-C dev board with  TM4C123GH6PM with Code Composer Studio Version: 6.1.2.00014 on OSX. I have 2 question/error:

1,

My program runs only if I start with debugger. If I connects an external power supply for the board the power looks like not running (does nothing). After I press the reset button on the board the program starts to run. What can be the problem? (Different project with same board works fine.) I think some project setup could be the problem, but i do not find it.

2,
I am using PWM modules to generate some PWM signal for servos. When I start a debug session often the servos acts like crazy, do random moves. It is between the starts of the debug session and init the PWM module. If I do not press the run button is appears randomly, too. I realized this bug when I used a breakpoint in uart interrupt but only for short times. The servo connected directly to Tiva pin and gets power from external power module. There are no problems if the program runs.

Thank you for the help!

  • 0
    TI__Guru**** 244440 points
    Hello Poc,

    Regarding Issue-1, the most probable cause is going to be an incorrect startup_ccs.c file or a missing startup_ccs.c file.

    Issue-2: Have you cleared the STALL bit in the PWM module. When in debug mode the STALL bit default behavior is to stall the PWM signal when single stepping which may cause such an issue.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 100 points
    Than you for the fast answare.

    Issue 1:
    I am using the original tm4c123gh6pm_startup_ccs.c with some added interrupts:
    "// To be added by user
    extern void UARTIntHandler(void);
    extern void UARTIntHandler2(void);"

    " UARTIntHandler, // UART0 Rx and Tx
    UARTIntHandler2, // UART2 Rx and Tx"

    It works with another projects.


    Issue 2:
    As I am using the PWM api I can not know the exact work of it. For sample here is my config:
    " case SERVO_MOD0_GEN0_NBR0:
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB); //PORTB enable
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM0); //PWM0 enable
    ROM_SysCtlPWMClockSet(SYSCTL_PWMDIV_64); //sysclk=80MHz, PWM_clock=80MHz/64 1250->1ms
    ROM_GPIOPinConfigure(GPIO_PB6_M0PWM0); //configure PB6 as PWM output
    ROM_GPIOPinTypePWM(GPIO_PORTB_BASE, GPIO_PIN_6);
    ROM_PWMGenConfigure(PWM0_BASE, PWM_GEN_0, PWM_GEN_MODE_DOWN); //configure PWM module
    ROM_PWMGenPeriodSet(PWM0_BASE, PWM_GEN_0,period_value); //set period time
    ROM_PWMPulseWidthSet(PWM0_BASE, PWM_OUT_0,position_value); //set default value
    ROM_PWMOutputState(PWM0_BASE,PWM_OUT_0_BIT, true); //PWM output state
    ROM_PWMGenEnable(PWM0_BASE, PWM_GEN_0); //enable PWM gen
    break;"
  • 0 in reply to abonyi zoltán
    Guru 117855 points

    Adding parameter, "PWM_GEN_MODE_DBG_STOP" to your, "ROM_PWMGenConfigure()" will halt the PWM output when you stop the debugger.


    As to your "uncontrolled" servo output @ power-on - perhaps your servo requires a pull-down resistor (or other disabling) to keep it quiet until the MCU fully brings up its PWM peripheral.

  • 0 in reply to cb1_mobile
    Guru 92251 points

    cb1_mobile said:
    Adding parameter, "PWM_GEN_MODE_DBG_STOP" to your, "ROM_PWMGenConfigure()" will halt the PWM output when you stop the debugger.

    PWM_GEN_MODE_DBG_STOP has the value zero, which means the "default" is for the PWM to stop running in debug mode.

    In this case i think the PWM is required to continue running in debug mode, in which case the PWM_GEN_MODE_DBG_RUN parameter (value 4) should be added to the PWMGenConfigure() call.

  • 0 in reply to Chester Gillon
    Guru 117855 points

    May I note that for over 5 years we've employed that exact parameter (under the robust StellarisWare 9453) and ALWAYS the PWM (properly) halts during an exit from debug.

    My post here follows upon vendor Amit's suggestion to, "Stall the Debugger."   I've provided the necessary detail to accomplish - just that...

    We do not want PWM to continue when we break from the program - with J-Link attached - all kinds of mayhem may then result.

    I make no claim for having invented this method - it is "textbook" from LMI's BLDC-RDK code listing - and every "pro" BLDC developer we know (that's many) want to halt their PWM output when they halt the debugger.   That's quite standard - hard to imagine your point...

    Of course when the debugger is removed - and the board operated "Stand-Alone" - the PWM (then) outputs "exactly" as required.

  • 0 in reply to cb1_mobile
    Guru 117855 points

    For those interested - follows the (unedited) description directly from "SW-DRL_UG_9453" regarding, "PWM_GEN_MODE_DBG_STOP."  The other option is, "PWM_GEN_MODE_DBG_RUN."   Relying upon "default" values - as another here seems to suggest - when something critical such as motor control is to be performed - is NOT recommended.   (and not how one co-founds - takes tech firm public!)

    "The PWM generator can either pause or continue running when the processor is stopped via the debugger. If configured to pause, it continues to count until it reaches zero, at which point it pauses until the processor is restarted. If configured to continue running, it keeps counting as if nothing had happened."

  • 0 in reply to cb1_mobile
    Guru 92251 points

    cb1_mobile said:
    Relying upon "default" values - as another here seems to suggest - when something critical such as motor control is to be performed - is NOT recommended.   (and not how one co-founds - takes tech firm public!)

    I wasn't recommending relying upon "default" values.

    The point I was trying to make was that the original poster's call to PWMGenConfigure() was the following, in which neither the PWM_GEN_MODE_DBG_RUN nor PWM_GEN_MODE_DBG_STOP parameters were passed:

    poc_zoli said:
    ROM_PWMGenConfigure(PWM0_BASE, PWM_GEN_0, PWM_GEN_MODE_DOWN); //configure PWM module

    Since the PWM_GEN_MODE_DBG_STOP parameter has the value zero this means both:

    ROM_PWMGenConfigure(PWM0_BASE, PWM_GEN_0, PWM_GEN_MODE_DOWN)

    and

     ROM_PWMGenConfigure(PWM0_BASE, PWM_GEN_0, PWM_GEN_MODE_DOWN | PWM_GEN_MODE_DBG_STOP)

    will both cause the same behavior of the PWM generator pausing when the processor is stopped via the debugger. Therefore, while adding the PWM_GEN_MODE_DBG_STOP parameter clarifies the intent it won't change the PWM behavior.

  • 0 in reply to Chester Gillon
    Guru 117855 points

    Thus - that method relies upon a default behavior - which may change at any time as new API code releases land.

    And - perhaps of higher importance/impact - poster's must make the effort to read, understand & comply w/the descriptions provided w/in the API.   (i.e. "some" thought, effort, consideration IS required.)   The "method" suggested by another "excuses" one from such directed effort - (rely upon blind fate!) thus is a "disaster in the making" and should be avoided!

    I stand by clarity of intent - and positive action as opposed to "reliance upon defaults and/or simple "bit-set" luck"  - which may change w/out notice - at any time...

    For those seeking to "one day" interest Venture firms (raise funds) - the method I've described (clear, positive action) proves far more desirable and "Investor friendly/ready."   The alternative - not so much...  And often will get you, "Shown to the door!"   Bad idea - do not do it!

  • 0 in reply to abonyi zoltán
    TI__Guru**** 244440 points
    Hello Poc,

    Also please check what the cmd file for the linker is configured for. When performing a debug session, also check the locations 0x0 and 0x4 of the flash.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 100 points

    Hi Amit and others,

    For the PWM problem:
    I added external pulldown resistors (10k ohm) for the PWM outputs. It was not helpful. I made a measure with a logic analyzer. The output changes randomly between high and low level during programming. The used servos are too good :D They are looks like digital servos with memory and saves the latest acceptable inputs. ( We modified the servos to turn around endlessly.) It keeps turning until I disconect the power supply or the servo receives a new acceptable servo signal.
    Is it possible to add larger pulldown resistor or disabling the outputs by software?

    For start problem:
    For test reason I imported the blinky example. It started after I gave power supply for the panel. As I try-ed mani setup variables in CCS debug settings I added my files to the blinky project. After a rebuild the software do not starts again.


    I think it can be easier if I share my complet project. It is commented and writed mostly in english. 

  • 0 in reply to abonyi zoltán
    Guru 92251 points

    poc_zoli said:
    I think it can be easier if I share my complet project.

    Can you attach your project to this forum, as I don't have access to Dropbox.

  • 0
    Guru 92251 points

    poc_zoli said:
    1,

    My program runs only if I start with debugger. If I connects an external power supply for the board the power looks like not running (does nothing). After I press the reset button on the board the program starts to run.

    Using your attached project, I can repeat the behavior when loaded into a EK-TM4C123GXL launchpad in that:

    a) When started a debug session and set the program running, the green LED was flashing.

    b) After power-cycling the launchpad the green LED was off, meaning the program was not running. I attached the debugger to the failed program, without reseting it, and the debugger showed the program was in a call to UARTCharGet(UART2_BASE) from the UARTIntHandler.

    In my case originally there is is nothing connected to the UART2 receive input, but even after connecting UART 2 RX input (PD6) to 3.3V I still get the same failure after a power-up.

    Don't yet understand what is triggering the receive interrupt, but yet the UARTCharGet call blocks.

  • 0 in reply to Chester Gillon
    Prodigy 100 points
    Hi Chester,

    Thank you for your answer. I'll check my uart.

    Did you use a specific external debugger or the built in one? Can you link me a description for it?
  • 0 in reply to abonyi zoltán
    Guru 92251 points

    poc_zoli said:
    Did you use a specific external debugger or the built in one?

    I used the built-in debugger on the TM4C123 launchpad.

    For how to connect the debugger to a running target, see http://processors.wiki.ti.com/index.php/MSP430_-_Connecting_to_a_running_target. The referenced Wiki page is written for MPP430 devices, but also applies to Tiva devices.

  • 0 in reply to Chester Gillon
    Prodigy 100 points
    Thank you, I will check it.

    And do you have idea why my servos start during programming? Basically it means GPIOs switch state more times during programming. Is it normal and I have to take care about it by hardware or should I disable this behaviour somehow?
  • 0 in reply to abonyi zoltán
    Guru 92251 points

    poc_zoli said:
    And do you have idea why my servos start during programming?

    Can you clarify if the problem occurs when downloading a new program and/or single stepping a program?

    poc_zoli said:
    Is it normal and I have to take care about it by hardware or should I disable this behaviour somehow?

    From a quick search, the behavior of PWM controlled servos is not defined if the PWM signal stops - not sure if the servo will hold it's last position or will start to drift. Are there any pull-down resistors on the PWM outputs to the servos?

  • 0 in reply to abonyi zoltán
    TI__Guru**** 244440 points
    Hello Poc

    The issue seems to be that it is stuck in UARTIntHandler statement

    uart_data = UARTCharGet(UART2_BASE);

    1. There is no interrupt clear
    2. This interrupt handler is for UART0, so why is UART2 being polled?

    After making the change to UART0_BASE, the LED is blinking after Power On as well.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 92251 points

    Amit Ashara said:
    This interrupt handler is for UART0, so why is UART2 being polled?

    Thanks for pointing out the mismatch in the interrupt handler. I had already posted that the code was getting stuck in the UARTCharGet(UART2_BASE) call, but hadn't noticed that the call to UARTCharGet(UART2_BASE) was inside the interrupt handler for UART0 !

  • 0 in reply to Chester Gillon
    Guru 47900 points
    Agree that for safety/security pull-down resistors should prove useful.

    That said - in our (long) use of PWM outputs from multiple vendors - when the debugger or the PWM toggle is halted - that PWM pin reverts to its "inactive" state. (usually logic low)

    However - should the MCU become disordered - or MCU to Servo connection "break" - the presence of said pull-down R - @ the servo (NOT the MCU) - may, "Save the day."