• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 16 subscribers
  • Views 1094 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.

CC1120 connected to external MCU, GPIO not working

Tom Cooper
Prodigy 250 points
Other Parts Discussed in Thread: CC1120

My CC1120 is connected to a STM32 MCU via SPI, and I am able to successfully read/write to registers. However I need to send a MARC_MCU_WAKEUP interrupt signal via GPIO, but I can't seem to get the pin to output anything other than low (using an oscope). Since it's possible there is no interrupt triggered with my Rx code, I've also tried simply outputting the EXT_CLOCK and CHIP_RDY signals to see if the GPIO3 pin works but no luck. I can verify I am writing the correct values to IOCFG3 register (20, 49, or 50 in decimal).

Is there anymore config needed other than the IOCFG3 register? Is there a simple test I can perform to ensure that the GPIO pin can even go high?

Thanks for your help!

Edit: I should also mention that I'm using the EM I/O breakout pins on the TrxEB eval board (for working SPI and non-working GPIO), following Section 7.3 in http://www.ti.com/lit/ug/swru294a/swru294a.pdf

  • 0
    TI__Guru**** 317180 points

    To understand your setup: Do you use a CC1120EM on TRXEB and then connecting the SPI lines to a STM32 board?

  • 0 in reply to TER
    Prodigy 250 points

    TER said:

    To understand your setup: Do you use a CC1120EM on TRXEB and then connecting the SPI lines to a STM32 board?

    Correct. I have also tried enabling the TrxEB GPIO when it is disconnected from the STM32 GPIO just to isolate and see if I can output anything.
  • 0 in reply to Tom Cooper
    TI__Guru**** 317180 points

    Without connecting the STM32, do you manage to toggle the GPIO using SmartRF Studio to control the TRXEB? I assume that you have checked that you have connected the scope to the correct pin.

  • 0 in reply to TER
    Prodigy 250 points

    TER said:

    Without connecting the STM32, do you manage to toggle the GPIO using SmartRF Studio to control the TRXEB? I assume that you have checked that you have connected the scope to the correct pin.

    No, I try writing 0x14, 0x31, or 0x32 to IOCFG2.GPIO2_CFG in the SmartRF Studio register view, with the oscope on GPIO2 pin (P7.4 I think). I have been able to Tx and Rx packets between two CC1120 TrxEBs just to assert that that works.
  • 0 in reply to Tom Cooper
    TI__Guru**** 317180 points

    If you write 0x33 and 0x73 you should be able to toggle the pin. (logic '0' and logic '1' on the pin). It sounds like something very basic that is wrong since it sounds like you do everything correct.

    - Could you snap a picture of the scope probe attached just to make sure the connection?

    - Could you try to write 0x33/0x73 to all GPIOs to see if you get some action?

  • 0 in reply to TER
    Prodigy 250 points

    TER said:

    If you write 0x33 and 0x73 you should be able to toggle the pin. (logic '0' and logic '1' on the pin). It sounds like something very basic that is wrong since it sounds like you do everything correct.

    - Could you snap a picture of the scope probe attached just to make sure the connection?

    - Could you try to write 0x33/0x73 to all GPIOs to see if you get some action?

    I also think I am missing something basic. Just to be thorough, I also tried all the USB mode switch combos (enable/smartrf/uart) to no avail. Toggling 0x73/0x33 in SmartRF Studio registers did nothing for GPIO[0,2,3], but GPIO1 (tied to MISO line) was able to go low and high as expected. I don't have anything to take a photo with at the moment, but I can assure you that the oscope is hooked up properly, as I am able to see the low/high of GPIO1. The GPIO[0,2,3] pins just aren't working still...
  • 0 in reply to TER
    Prodigy 250 points

    Well I feel dumb, one of the oscope probe cables is faulty while the other one (which I just happened to check GPIO1/MISO with) works fine. Thanks for your time and help walking me through it though.