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

TMS320F280049C: Unexpectedly Short GPIO Pulse

Gökhan Bayraktar
Prodigy 100 points
Part Number: TMS320F280049C
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hello,

I’m working on a project using the TMS320F280049C MCU and I’ve encountered an unexpected behavior with one of the GPIO pins. In my application, I am controlling GPIO22, GPIO15, and GPIO14 using the GPADAT register with a 2D array and an index as follow:

GpioDataRegs.GPADAT.bit.GPIO22 = muxStates[currentMuxIndex][0];
GpioDataRegs.GPADAT.bit.GPIO15 = muxStates[currentMuxIndex][1];
GpioDataRegs.GPADAT.bit.GPIO14 = muxStates[currentMuxIndex][2];

With this code, either GPIO14 or GPIO15 (I can't recall exactly which one) behaves incorrectly. The pin goes HIGH as expected but remains HIGH for only ~20ns instead of the expected 10 µs. Interestingly, GPIO22 behaves correctly, and no such issue occurs with that pin.

When I change the GPIO assignment order like this, the issue seems to disappear:

GpioDataRegs.GPADAT.bit.GPIO15 = muxStates[currentMuxIndex][1];
GpioDataRegs.GPADAT.bit.GPIO22 = muxStates[currentMuxIndex][0];
GpioDataRegs.GPADAT.bit.GPIO14 = muxStates[currentMuxIndex][2];

I guess setting adjacent GPIO causes some digital signal conflict but this is a quite rough guess.

I configured all the GPIO pin from sysconfig with fallowing settings:




Any explanation would be highly appreciated.

Thanks,

Gökhan

  • 0
    TI__Mastermind 18341 points

    Hi Gokhan

    Thanks for reaching out. I haven't seen this issue before. Do you see the same short GPIO pulse behavior when using the DriverLib version of setting the GPIO output, like below:

    GPIO_writePin(22, muxStates[currentMuxIndex][0]);
GPIO_writePin(15, muxStates[currentMuxIndex][1]);
GPIO_writePin(14, muxStates[currentMuxIndex][2]);

    Also, make sure you are only calling the Board_init() function once during initialization and not repeatedly throughout your program. 

    Regards,

    Peter

  • 0
    Prodigy 100 points

    Hi Peter,

    Thanks for reaching out.

    I will try the driverlib function however ideally that would not be the solution i want because the execution time is critical here.

    Beside that i am sure board_init() is called once.

    İ still guess setting adjacent gpio succesively is the reason. 

    When i set GPIO22 and 23 succesively, the same problem still exist at either 22 or 23.

  • 0 in reply to Gökhan Bayraktar
    Prodigy 100 points

    Hello Again,

    I tried the driverlib function and it worked fine. 
    But still I would love know why did this occur using the GPADAT register

  • 0 in reply to Gökhan Bayraktar
    TI__Mastermind 18341 points

    Hi Gokhan,

    Interesting that you see this behavior. If you remove the DEBUG predefined symbol, then the GPIO_writePin function will remove any unnecessary checks in the code, this should be the same timing as if you were to directly write to the GPADAT register. Let me consult with some colleagues to see if this has been seen before

    Regards,

    Peter

  • 0 in reply to Peter Luong1
    TI__Mastermind 18341 points

    Hi Gokhan,

    There is a GPIO notice in the errata Open-Drain Configuration May Drive a Short High Pulse. 

    Can you verify the GPIO Pad Config register to check if possibly your GPIO is getting changed to Open Drain Config after the SysConfig board initialization?

    Regards,

    Peter

  • 0 in reply to Peter Luong1
    Prodigy 100 points

    Hi Peter,
    I checked the GPAODR register in debug while the setting codes are like below ( the faulty ordering):

    GpioDataRegs.GPADAT.bit.GPIO22 = muxStates[currentMuxIndex][0];
    GpioDataRegs.GPADAT.bit.GPIO15 = muxStates[currentMuxIndex][1];
    GpioDataRegs.GPADAT.bit.GPIO14 = muxStates[currentMuxIndex][2];

    All the GPIO pins has the GPAODR value 0 which means they are in push-pull output mode as they are set in syscfg.

  • 0 in reply to Gökhan Bayraktar
    TI__Mastermind 18341 points

    Hi Gokhan,

    Thanks for confirming that. I'm testing this on my end currently to understand why this behavior is happening, will check with our design team for better understanding

    Regards,

    Peter