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.

TMS320F280049C: Processor pins keep in hi impedance state

Part Number: TMS320F280049C
Other Parts Discussed in Thread: LAUNCHXL-F280049C, C2000WARE, DRV8353

Hi,

I have a LAUNCHXL-F280049C with motor control firmware (ported from x0025 processor).

When loading this code to the processor, the 2 LED pins (GPIO23 and 34 acc. to the datasheet) keep in hi-impedance state.

When loading another program of mine, the LED's will turn on/off (immediately after main())

What could be the issue here? Linker file broken?

Best regards,

Ruud

  • Hello Ruud,

    I am assuming you expect the LED pins to turn on/off with your motor control firmware? Have you checked the contents of the GPIO control and data register to verify if your software has configured the GPIO pins correctly? You can reference the LED blink example in C2000ware for reference. You can also run this example on the LaunchPad if you suspect some hardware issue.

  • Hi Gus,

    I have the motor control firmware (partially) ported and in use. With the debugger running to main() I configured the ports and check if the LED's are turning on/off (before the hall initalisation). The IO pins are configured as in my other firmware and there it works okay. When loading another program of mine the LED's are working, so no hardware issues here.

    I use the GPIO_writePin(23, 1); and GPIO_togglePin(23); functions.

    The difference with my other proram is I use driverlib there. So just removed all files in src_driver and included driverlib. Still not working.

    However when using the toggle register the LED's will toggle.

    ###

    Just set the Optimization level from OFF to 0 (Register Optimizations). Now the pins will toggle, but no breakpoints are possible (on GPIO_togglePin function) and code stepping in debug is not really possible. 

    In my other firmware breakpoints and code stepping is possible in both Optimization OFF and 0 (Register Optimizations). 

    Both code is running from flash and compiler 21.6LTS is used

    Bet regards,

    Ruud

  • Ruud,

    The debugger uses hardware breakpoints when your code is running from Flash. You are limited to 2 HW breakpoints. You may want to check  View>Breakpoints in CCS to see if you have too many HW breakpoints enabled. More information on HW breakpoints below.

    https://software-dl.ti.com/ccs/esd/documents/ccs_breakpoint_watchpoint_c2000.html

  • I bought a Launchpad f280025C, did a re-installation of the motor control software, imported a new project exactly as the tutorial explained. Connected the f280025C board to the DRV8352RS-EVM board. Followed the tutorial exactly

    The debugger hits the code for the LED:

                if(systemVars.counterLED > (uint16_t)(LED_BLINK_FREQ_Hz * 1000))
                {
                    HAL_toggleLED(halHandle, HAL_GPIO_LED2C);
    
                    systemVars.counterLED = 0;
                }

    NO breakpoint possible on the HAL_toggleLED line, but this may be due to the optimization level. Breakpoint is set on systemVars.counterLED = 0; and the debugger stops. NO led is toggling.

    LED1 is ON (3V3).

    Any thoughts?

  • Hello Ruud,

    I am not familiar with this firmware. How is HAL_toggleLED() defined? What is the definition of HAL_GPIO_LED2C? Can you use the View>Registers window in CCS to verify that the GPIO pin mux is configured correctly? You can also write directly to the GPIO toggle register there to verify that LED does indeed turn on/off.

  • Hello Gus,

    It seems that 'out of the box' the HAL_GPIO_LED2C can't be used, since it is used as the FAULTn pin of the DRV8353 driver.

    I changed it to HAL_GPIO_LED1C and set it as output, now 1 LED is toggling. 

    I find it very strange that the LED wasn't working out of the box, because -at first- it's the most important user feedback.

    Best regards,

    Ruud