• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 472 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.

TMS320F28075: Debugging Issue on Custom TMS320F28075 Board – GPIO Output Not Observed

Tasmiya
Prodigy 200 points

Part Number: TMS320F28075
Other Parts Discussed in Thread: TMS320F28379D, C2000WARE

Tool/software:

Hi Team,

I am working on the TMS320F28075 IC and have designed a custom microcontroller card, ensuring that all necessary connections required for the IC to function are made as per the datasheet.

Previously, I successfully ran the code on the C2000 LaunchPad (TMS320F28379D). However, now I am debugging the same code on my custom board using JTAG TMS320-XDS100-V2. All JTAG connections have been made as per the datasheet, and when tested in CCS, the target status shows no errors and connects properly.

Observations:

  • Code Behavior:

    • The code successfully builds and debugs, but no expected output is observed.
    • For example, when setting GPIO20 high, there is no change on the pin.
    • I have tested multiple GPIOs and encountered the same issue.

  • Power Consumption:

    • Idle state (no code flashed): 30mA
    • During flashing via JTAG: Spikes to 120mA
    • After flashing: Drops to 70mA
    • Compared to the C2000 LaunchPad, in which the input current increased further after flashing, which is not happening on my custom board.

Assistance Required:

  • Could you help me understand what might be going wrong and what debugging steps I should take?
  • Since this is an independent board based on TMS320F28075 (100-pin), do I need to add any additional initialization lines in the code to ensure proper execution and code retention after debugging?

Below is the relevant portion of my code:

#include "driverlib.h"
#include "device.h"

void main(void)
{
    //
    // Initialize device clock and peripherals
    //
    Device_init();
    Device_initGPIO(); // Initialize GPIOs

    //
    // Configure GPIO20 as a GPIO output
    //
    GPIO_setPinConfig(GPIO_20_GPIO20); // Ensure GPIO20 is in GPIO mode
    GPIO_setPadConfig(20, GPIO_PIN_TYPE_STD); // Standard push-pull
    GPIO_setDirectionMode(20, GPIO_DIR_MODE_OUT); // Set as output

    //
    // Set GPIO20 High
    //
    GPIO_writePin(20, 1);

    //
    // Infinite loop
    //
    while(1);
}

Best regards,

Tasmiya

  • 0
    TI__Mastermind 18146 points

    Hi Tasmiya,

    Can you check if the Xrsn is held high (3.3V) ?

    Then check the GPIO configurations, when you write 1 to the Pin 20 can you check the GPIO data register to see if its indeed set ?

    Thanks

  • 0 in reply to Prarthan Bhatt
    Prodigy 200 points

    Hi,

    Yes, Xrsn is indeed held high at 3.3V.

    The issue seems to be with this line: InitSysCtrl();. When this line is included, and I write 1 to GPIO pin 20, there is no output, and the program stops at the following line:

    ClkCfgRegs.SYSPLLMULT.all = ((fmult << 8U) | imult);
    It then waits in this loop:
    while(ClkCfgRegs.SYSPLLSTS.bit.LOCKS != 1)

    However, when I run the code without the InitSysCtrl(); line, I can see the GPIO20 pin outputting as expected, and the data register shows 1.

    The issue may lie in how the system clock is being configured. Since I'm using the internal oscillator for the control card, I believe the PLL initialization is causing a stall in the clock locking process.

    Could you please provide me with sample code or examples for configuring and using the internal oscillator correctly? This would help in troubleshooting and resolving the issue.

    Below is full code:

    #include "F28x_Project.h"

    void main() {

    InitSysCtrl();

    EALLOW;
    GpioCtrlRegs.GPAMUX2.bit.GPIO20 = 0; 
    GpioCtrlRegs.GPADIR.bit.GPIO20 = 1;
    EDIS;

    GpioDataRegs.GPASET.bit.GPIO20 = 1;
    while (1) {

    }
    }

    Thanks

  • 0 in reply to Tasmiya
    Prodigy 200 points

    Hi ,

    I hope this email finds you well. I previously reached out regarding an issue where I observed output on the pins but was unable to achieve the expected behavior. Following your recommendation to check if the XRSn pin is held high at 3.3V, I have confirmed that the XRSn pin is properly held at 3.3V.

    However, I have now identified that the issue might be related to the PLL (Phase-Locked Loop) block not locking correctly. I have not mentioned this in my previous communication, but I believe this could be the root cause of the issue I am facing.

    When I flash the code, the output of ClkCfgRegs.SYSPLLSTS.bit.LOCKS in the expression window is always 0, indicating that the PLL is not locking as expected. I would appreciate it if you could guide me on how to resolve this issue and get the PLL to lock correctly.

    Thanks

  • 0 in reply to Tasmiya
    TI__Mastermind 18146 points

    Hi,

    Are you using the same function as it is implemented in c2000ware example for TMS320F28075 device. I suspect there will be some changes between the devices (TMS320F28379D vs TMS320F28075 ).

    Can you try and run the gpio_ex2_toggle from the C2000Ware directory - ..\driverlib\f2807x\examples\cpu1\gpio

    Let me know what you notice in this example.

    Thanks

  • 0 in reply to Prarthan Bhatt
    Prodigy 200 points

    Hi,

    I tried building and executing the gpio_ex2_toggle example from C2000Ware on the TMS320F28075. However, I encountered the following issues in different execution modes:

    1. RAM Mode Issue:

    When running the code in RAM mode, it redirects to the following error:

    void __error__(const char *filename, uint32_t line)  
{  
    // An ASSERT condition was evaluated as false.  
    ESTOP0;  
}

    2. Flash Mode Issue:

    When running the same code in Flash mode, I get the following error in the console:

    C28xx_CPU1: Error occurred during flash operation: Timed out waiting for target to halt while executing wr_pll.alg  
C28xx_CPU1: Error writing the PLL values (Flash algorithm timed out). Operation cancelled.  
C28xx_CPU1: Perform a debugger reset and execute the Boot-ROM code (click on the RESUME button in CCS debug window) before erasing/loading the Flash. If that does not help to perform a successful Flash erase/load, check the Reset cause (RESC) register, NMI shadow flag (NMISHDFLG) register, and the Boot-ROM status register for further debugging.  
C28xx_CPU1: File Loader: Memory write failed: Unknown error

    Request for Assistance:

    Could you please provide insights into what might be causing these issues and suggest the appropriate steps to resolve them?

    Thanks

  • 0 in reply to Tasmiya
    TI__Mastermind 18146 points

    Hi,

    Tasmiya said:

    1. RAM Mode Issue:

    When running the code in RAM mode, it redirects to the following error:

    Please check where this ASSERT error condition gets triggered. Should be able to trace from call stack 

    Where you able to program the code in RAM ?

    Tasmiya said:

    When running the same code in Flash mode, I get the following error in the console:

    Fullscreen
    1
    2
    3
    4
    C28xx_CPU1: Error occurred during flash operation: Timed out waiting for target to halt while executing wr_pll.alg
    C28xx_CPU1: Error writing the PLL values (Flash algorithm timed out). Operation cancelled.
    C28xx_CPU1: Perform a debugger reset and execute the Boot-ROM code (click on the RESUME button in CCS debug window) before erasing/loading the Flash. If that does not help to perform a successful Flash erase/load, check the Reset cause (RESC) register, NMI shadow flag (NMISHDFLG) register, and the Boot-ROM status register for further debugging.
    C28xx_CPU1: File Loader: Memory write failed: Unknown error

    The above looks like flash programming error ? Were you able to load code in flash ?

    Thanks