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

Tasmiya

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:

Fullscreen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#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
    //
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#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

8 months ago

0 Prarthan Bhatt 8 months ago

TI__Genius 13475 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 Tasmiya 8 months ago 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:

Fullscreen

1
ClkCfgRegs.SYSPLLMULT.all = ((fmult << 8U) | imult);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ClkCfgRegs.SYSPLLMULT.all = ((fmult << 8U) | imult);

It then waits in this loop:

Fullscreen

1
while(ClkCfgRegs.SYSPLLSTS.bit.LOCKS != 1)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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 Tasmiya 8 months ago 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 Prarthan Bhatt 8 months ago in reply to Tasmiya

TI__Genius 13475 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 Tasmiya 8 months ago 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:

Fullscreen

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

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:

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  
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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 Prarthan Bhatt 8 months ago in reply to Tasmiya

TI__Genius 13475 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

C2000™︎ microcontrollers

C2000 microcontrollers forum

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

Observations:

Assistance Required:

1. RAM Mode Issue:

2. Flash Mode Issue:

Request for Assistance:

1. RAM Mode Issue: