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

TMS320F28069: GPIO Output Toggling Glitch

Peter Baier
Prodigy 20 points
Part Number: TMS320F28069


Tool/software:

Hey,

I am noticing something strange with specific GPIOs that are configured as outputs. The code below is how GPIO30 and GPIO25 are configured. While my project is running, in a scenario with a lot of switching noise, these GPIOs tend to “toggle” themselves without me writing any command to do so.

GpioCtrlRegs.GPAMUX2.bit.GPIO30 = 0;                 // GPIO30 = GPIO30

GpioCtrlRegs.GPADIR.bit.GPIO30 = 1;       // GPIO30 = OUTPUT

GpioCtrlRegs.GPAPUD.bit.GPIO30 = 0;     // Disable pullup on GPIO30

GpioCtrlRegs.GPAMUX2.bit.GPIO25 = 0;                 // GPIO25 = GPIO25

GpioCtrlRegs.GPADIR.bit.GPIO25 = 1;       // GPIO25 = OUTPUT

GpioCtrlRegs.GPAPUD.bit.GPIO25 = 0;     // Disable pullup on GPIO25

These GPIO outputs are some of few that are routed right under some High Voltage switching, it will pick up a lot of noise in certain scenarios. When the project is in a low noise scenario, the GPIO behaves fine, only doing exactly what it is programmed to do. But when it is in a high noise scenario sometimes randomly this GPIO will toggle on its own. While monitoring the GpioDataRegs.GPADAT.bit.GPIO30 bit during debug, it will change from 0->1 or 1->0 on its own. I have removed all set/clear/dat commands to just observe the behavior all on its own. Below is a screenshot of GPIO30 and GPIO25 behaving this way (they both are routed near the HV switching noise source).

So my question is why is this happening? If my GPIO is set as an output, it shouldn’t toggle/latch/change states without my code telling it to. Does high noise have a change to influence this GPIO to change states?

Our current work around right now is to assume this GPIO is constantly being read by the micro, as if it were an input, and maybe tricking itself when it reads noise and toggles itself. So, the below code is additional Qualification Window GPIO setup, assuming as if it were an input. Below the code is a screenshot of GPIO30 and GPIO25 with this extra setup.

GpioCtrlRegs.GPACTRL.bit.QUALPRD3 = 0x4B;      //(75x2)/(90Mhz)=period

GpioCtrlRegs.GPAQSEL2.bit.GPIO30 = 2;                 //6 sampling window

GpioCtrlRegs.GPAQSEL2.bit.GPIO25 = 2;                 //6 sampling window

Thanks for any help or insight, it is appreciated

  • 0
    TI__Genius 13865 points

    Hi Peter,

    The input qualification setup only applies to the gpio input path as shown in the figure below

    Do you know what level disturbance can be caused due the High voltage rail close to this gpio ?

    Thanks

  • 0 in reply to Prarthan Bhatt
    Prodigy 20 points

    Correct, to my understanding input qualification should not influence the behavior of the GPIO setup as an output, but it is. Even though the GPIO is setup as an output, does the micro still constantly read the data of this pin? That was why I even thought to change the input qualification in the first place. 

    The HV switching nearby is causing about 200mvp-p of noise on the GPIOs.

    Thanks

  • 0 in reply to Peter Baier
    TI__Genius 13865 points

    Hi Peter,

    Are you sure the pins are toggling because of noise on the input.

    Otherwise you shall see small abrupt pulses but rather in the image I am seeing a rather bigger pulse also it can be case where normally the noise coupling is lower put some instances where the noise is greater than VDDIO ?
    Thanks

  • 0 in reply to Prarthan Bhatt
    Prodigy 20 points

    Currently in code I do not have any commands to change the state of these GPIO outputs. So right now there is nothing controlling these GPIO outputs and they have only been changing "on their own" during high noise 

    The screenshot of the failure above is just one example of the failure, during high noise scenarios the GPIOs states are random. Sometimes staying in a high or low state from a couple milliseconds to a few seconds before toggling on its own.