Funny Phenomenon when changing states of signals in DSP

[Chris_WMS]

Hi, I would like to seek some help in DSP Programming.

I'm using simple coding to turn on (HIGH) and off (LOW) 2 PORTS (PORTB (GPIO 39-47) and PORTC (GPIO 64-87)) GPIO in TMS320F28335 using CCS Composer Ver. 11.

The coding is as follows:

Code: [Select]

#include "DSP2833x_Device.h"     // DSP2833x Headerfile Include File
#include "DSP2833x_Examples.h"   // DSP2833x Examples Include File

void configtestled(void);
void main(void)
{
    // Step 1. Initialize System Control:
    // PLL, WatchDog, enable Peripheral Clocks
    // This example function is found in the DSP2833x_SysCtrl.c file.
       InitSysCtrl();

    // Step 2. Initalize GPIO:
    // This example function is found in the DSP2833x_Gpio.c file and
    // illustrates how to set the GPIO to it's default state.
    // InitGpio();  // Skipped for this example
       InitXintf16Gpio();   //zq

    // Step 3. Clear all interrupts and initialize PIE vector table:
    // Disable CPU interrupts
       DINT;

    // Initialize the PIE control registers to their default state.
    // The default state is all PIE interrupts disabled and flags
    // are cleared.
    // This function is found in the DSP2833x_PieCtrl.c file.
       InitPieCtrl();

    // Disable CPU interrupts and clear all CPU interrupt flags:
       IER = 0x0000;
       IFR = 0x0000;

    // Initialize the PIE vector table with pointers to the shell Interrupt
    // Service Routines (ISR).
    // This will populate the entire table, even if the interrupt
    // is not used in this example.  This is useful for debug purposes.
    // The shell ISR routines are found in DSP2833x_DefaultIsr.c.
    // This function is found in DSP2833x_PieVect.c.
       InitPieVectTable();
       configtestled();

       GpioDataRegs.GPBDAT.all = 0xFFFFFFFF;
       GpioDataRegs.GPCDAT.all = 0xFFFFFFFF;
       DELAY_US(50);

       while(1)
       {
           GpioDataRegs.GPBDAT.all =0x00000000;
           GpioDataRegs.GPCDAT.all =0x00000000;
           DELAY_US(500);
           GpioDataRegs.GPBDAT.all =0xFFFFFFFF;
           GpioDataRegs.GPCDAT.all =0xFFFFFFFF;
           DELAY_US(500);
       }
}

void configtestled(void)
{
EALLOW;
    GpioCtrlRegs.GPCMUX1.all =  0x00000000;  // All GPIO(C)s are GPIOs (GPIO 64 - 79)
    GpioCtrlRegs.GPCMUX2.all =  0x00000000;  // All GPIO(C)s are GPIOs (GPIO 80 - 87)
    GpioCtrlRegs.GPCDIR.all = 0xFFFFFFFF; //All GPIO(C)s are outputs
    GpioCtrlRegs.GPBMUX1.all =  0x00000000;  // All GPIO(B)s are GPIOs (GPIO 39 - 47)
//     GpioCtrlRegs.GPBMUX2.all =  0x00000000;  // All GPIO(B)s are GPIOs
    GpioCtrlRegs.GPBDIR.all = 0x0000FFFF; //All GPIO(B)s are outputs
    EDIS;
}

//===========================================================================
// No more.
//===========================================================================

The funny phenomenon that I'm facing is that when I compile and run the program only GPIO 39-47 in PORTB and GPIO 80-87 in PORT C are able to change states between HIGH (on) and LOW (off) while GPIO 64-79 in PORTC pins are always at LOW (off) state.

Kindly give me some advice on how can I solve this issue.

Thank you in advance.

Regards
Chris

[eutectique]

What assembly is generated from your source code? Does it do what you expect?

I am sure you can access the registers in the debugger directly. Do they contain the expected values?

[Phoenix]

Edited.

Sorry I missed the second function 😟

[DavidAlfa]

Probably assigned to some peripheral by default, I never used these.

[Phoenix]

Probably assigned to some peripheral by default, I never used these.

On these guys guys all io boot as inputs. Most with pull up activated, except PWM capable pins (allows you to use a resistor to define the off state). A quick debug session will tell if they have remained pin mux 0 or been changed somewhere.