• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 253 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.

CC2640R2F: GPIO Configuration Causing Startup Problems

Joshua Hess
Intellectual 490 points
Part Number: CC2640R2F

Tool/software: TI-RTOS

Hello,

I have been developing on the cc2640r2 platform around the simple_central example and I am very familiar with GPIO configuration and general driver usage. However, I recently performed a hardware revision to my project and added a small Mosfet with it's gate tied to DIO_9. Note I am also using this same model Mosfet in an almost identical situation (different IO pin) on the same board to control a small vibration motor. However, I have been experiencing some very strange behavior with DIO_9.

Originally, DIO_9 is used as part of the SPI bus, however, I have redefined these pins to be different and am using them without a problem. I have configured DIO_9 with the GPIO driver as an output, with high drive, default high, no pull and it seems to be affecting the startup process of the entire chip. I can successfully flash my program onto the chip, and it runs perfectly right after the flash. However, if a hard reset (push of the reset button on the launchpad) or power-cycle occur, the chip seems totally unresponsive. The only way around this that I have found is to disconnect both the Mosfet and the 10k pulldown resistor on the gate from the IO pin and the system responds totally normally. 

It seems that in debugging mode after a flash, something is flagged or skipped over that is different during normal operation after a reset. I am unsure what this could be. I have stripped down my code almost to the bare simple_central example and the problem still remains. I can't find anything special about DIO_9 in the documentation, it looks like a normal GPIO to me. Is there something I am missing? Is this pin being configured somewhere else that I don't see?

Any help is greatly appreciated, this is a tricky problem I have been stuck on for some time now.

Thanks!

  • 0
    TI__Guru**** 317180 points
    For ease of debugging, could you recreate the same issue starting from the empty example and post the code (including the board file) and the (relevant part of) you schematic?
  • 0 in reply to TER
    Intellectual 490 points

    Hello TER,

    Thank you for your reply. I think I have figured out what is going on but I would like to clarify some things. I isolated the problem in a new empty program as you suggested and the problem remained. I then started looking more closely a the hardware and the signal of the IO pin during resets and normal operation. I noticed that the IO pin during normal operation (when everything was working) was held high (3.3v)  as expected and during reset it would go low, also as expected. However, when the problem occurs, the pin only goes up to around 1.5v. I think the Mosfet was maybe pulling too much current at the beginning of its gate charging during the initialization sequence of the IO pins since I did not have a resistor in series to limit it. I added a 100k resistor in series and it has totally fixed the problem. 

    So with this in mind, I would like to understand what was happening here. I would guess that the IO pins check for a current overload during the chip initialization process and if it looks like a pin is going to pull too much current, the chip enters some kind of fault state. Is this accurate? I am also very curious to know why this did not occur in the debug state. It seems you would want protection the most during a debug session. Any information you have on this would be great to clear this up.

    Thanks!

  • 0 in reply to Joshua Hess
    TI__Guru**** 317180 points
    It sounds like something is trying to pull the pin high at the same time as you try to pull the same pin low which should not be possible.

    The IO pin check only make sure that you have define a given pin to one interface. Could you share the parts of the code where your code is different from the empty example?