• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 84 subscribers
  • Views 208 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F280039C: GPIOs specify the direction sequence

Johnny Chen
Expert 4080 points
Part Number: TMS320F280039C
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE

Hi Champ,

I am asking for my customer. It is urgent, kindly help.

It is written in TRM about "Before changing a pin to an output, load the output latch with the value to be driven by writing that value to the GPySET, GPyCLEAR, or GPyDAT registers. "

While the initialized code gen from the SysConfig GUI, it doesn't follow with the statement.

There are few questions needed the expert to kindly comment :

(1). By default, all GPIO pins are inputs. Must it follow as TRM written, write the value first, then change the GPIO direction ?

(2). Continuing with the first question, if I opposite the sequence (change the GPIO direction to output first, then write the value), will it have any effect or difference with the sequence ? Since we especially have the description in the TRM. If there is any details with it, we could discuss it by mail.

(3). Why doesn't the code generated by SysConfig GUI match the statement in TRM?

Thanks and regards,

Johnny

  • 0
    TI__Mastermind 20540 points

    Hi Johnny,

    Our GPIO expert Vince Toledo will get back to you as soon as possible, thank you for your patience.

    Luke

  • 0 in reply to Luke Jones
    TI__Mastermind 19795 points

    Hi Johnny,

    Thanks for your questions. In order of your original post:

    1. Yes, please follow TRM suggested process.

    2. I believe the main concern is having an undesired output value. For example, if you don't change the value first, and you can't have a "0" at the pin, then the pin will start at driven to "0" when set to output, which could be bad depending on what the GPIO is connected to in the system. It is always safer to load the expected value first.

    3. This is something that we will file and correct in a future update of Sysconfig, thank you for bringing this to our attention.

    Regards,

    Vince

  • 0 in reply to Vince
    TI__Expert 4080 points

    Hi Vince,

    Thanks for the reply.

    Relating to the second question, you mean there may be an undesired output value. May I offline ask you more about this through mail ? Not sure if my customer's issue is because of this. 

    Thank you for the support !

    Regards,

    Johnny

  • 0 in reply to Johnny Chen
    TI__Mastermind 19795 points

    Hi Johnny,

    You are correct in your understanding that there may be an undesired output value. I will provide an walk-through of why it may be an issue:

    • GPIO_setDirectionMode --> at this point in the code, the GPIO is set to output. Whatever the pin is set to output (0 by default) the pin will begin to output. So by default, the GPIO will begin to drive 0.
    • GPIO_setPadConfig, GPIO_setMasterCore, and GPIO_setQualificationMode --> set the pin type, core, and qual mode, output is still being driven to whatever the pin is set to output (0 by default)
    • GPIO_writePin --> the pin is now set to the desired value (0 or 1). For the last few lines of code, the GPIO will be driven to 0 by default.

    So you can see that there will be a short time where the GPIO is driven 0.

    I have filed a bug with the software team for this, which should be addressed in an upcoming release.

    Regards,

    Vince

  • 0 in reply to Vince
    TI__Genius 15235 points

    Dear Vince,

    In Johnny's and user's testing, the undesired GPIO low lasts for around 2 us to 3 us. That is, there are more than 120 cycles x 2. Does it make sense here? Why can it last so long for such a few lines?

    But it's true when we tried to modify the sequence following TRM, then the undesired GPIO low was gone.

    Wayne Huang

  • 0 in reply to Wayne Huang
    TI__Mastermind 19795 points

    Hi Wayne, Johnny,

    Thank you for your question. Kindly please keep posts to one thread/location.

    The number of cycles makes sense. Each of the C functions shown has lots of checks and verification. Please view the code for each function to see what is occurring during each.

    Summary of other posts:

    There is already a fixed file actually, see attached. This should be placed in your C2000Ware installation under:

    C:\ti\c2000\C2000Ware_{VERSION#}\driverlib\.meta\gpio

    Please replace the existing file with the attached file.

    gpio.board.c.xdt

    Regards,

    Vince