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

F28335 - GPIO problems when setting output.

E_
Intellectual 360 points


Hello,

I have got another question. I will try to explain keeping quite generic.

I am trying to run a program, that switches GPIO in certain patterns. This is to happen in an ADC isr.

The strange thing is, that when I step through it, the pins are set high and low without any issues, while there is no switching, when their is no break point.

At first I thought possible that one state is set for a too short period of time, although I was timing this quite slowly (supposing my mistake). But I noticed, that the last state that was set when stepping through, is remembered when letting the program run again and it wouldn't change.

I would be glad if you had any suggestions.

Regards,

E_

  • 0
    TI__Expert 8950 points

    E,


    Are you writing to the GPyDAT registers directly to set the output pattern? If so, you'll want to use the GPySET, GPyCLEAR, and GPyTOGGLE registers instead. There's a FAQ about this here:

    http://processors.wiki.ti.com/index.php/General_Purpose_IO_%28GPIO%29_FAQ_for_C2000#Q:_Back-to-back_DAT_register_writes_do_not_work_as_expected

  • 0 in reply to Adam Haun
    Intellectual 360 points

    Hello Adam,

    thank you for your quick answer. I tried those methods. I even tried using delays.
    Meanwhile I am getting all of them to work when it just comes to switching, but I'm still not satisfied.

    I am toggling GPIOs 32 and 34 for example, while 32 is the "MSB" and the other the LSB.
    Monitoring the outputs, I got this (sorry, my oscilloscope didn't recognize my USB):

    as you see, there is no clean toggling counting from 0 to 2. This strange overlap is a complementary pulse on the GPIOs at approx. 300Hz. GPIO34 should be switched off, before this "interference"  happens. I tried combining GPIO34 with 30, as they are connecerted to differ3ent multiplexers, but no change.

    33 and 31 on the other hand do perfectly "collaborate".

    regards,

    E_

  • 0 in reply to E_
    Intellectual 360 points

    solved that problem - it was on my side. (in most cases the problem is sitting in front of the screen)

    Now I am wondering why it worked with the other GPIOs (that is why I was confused), but ok, I will adapt code, so that no "accident" happens.