This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Setting value of GPIO Output

Hello all,

I am trying to do a simple task, yet I cannot manage to make it work. My goal is to use the GPIO 1.01 (defined as Digital I/O in the Data Sheet) as an output pin, set its logical value to High/Low and observe all changes in a Logic Analyzer.

The problem is that the pin stays always at High, no matter how many times I try to set it to Low.

Here is my implementation:

prj.conf

CONFIG_NCS_SAMPLES_DEFAULTS=y

CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="Nordic_LBS"

# Enable the LBS service
CONFIG_BT_LBS=y
CONFIG_BT_LBS_POLL_BUTTON=y
CONFIG_DK_LIBRARY=y

CONFIG_SPI=y

CONFIG_GPIO=y

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

CMakeLists.txt

cmake_minimum_required(VERSION 3.13.1)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(NONE)

target_sources(app PRIVATE
  src/main.c
)

zephyr_library_include_directories(.)

Code snippet in main.c where I configure the pin and try to modify its value.

  //Get GPIO_1 device
  struct device * trfEN;
  trfEN = device_get_binding("GPIO_1");
  if(trfEN == NULL) {
    printk("Could not get trfEN device\n");
  } else {
    printk("Found device trfEN\n");
  }
  
  //Configure pin as output
  gpio_pin_configure(trfEN, 1, GPIO_OUTPUT_LOW);  
  //Enable TRF by setting GPIO to HIGH
  int ret = gpio_pin_set(trfEN, 1, 1);  //Set pin 1.01 to 1
  if(ret != 0) {
    printk("Error setting pin to high\n");
  } else {
    printk("Pin set to high successfully\n");   //This line is printed -> No error setting pin
  }

  //Try to set pin to low
  k_sleep(K_MSEC(1000));
  ret = gpio_pin_set(trfEN, 1, 0);      //Set pin 1.01 to 0
  if(ret != 0) {
    printk("Error setting pin to high\n");
  } else {
    printk("Pin set to high successfully\n");   //This line is printed -> No error setting pin
  }

I attach also the output that I see with a logic analyzer:

Any idea where I am doing something wrong?

Many thanks in advance!

Parents
  • Hi,

    Have you tried setting any other pin on the board? Could you try cutting solder bridge SB30 on the board and see if it works now?

    regards

    Jared

  • Hello,

    I also tried with pin P0.11 as well. Unfortunately the result was the same.

    Regards.

  • Hi,

    Looking at the schematics for the DK I see that PIN P0.11 is also connected to a solder bridge that might need to be cut for it work. Could you try P0.04?

    regards

    Jared

  • Hi Jared,

    thanks for the reply, I was busy with other tasks but finally could get back to this issue.

    I managed to control various pins (P1.01, P0.11, P1.04) and even use P0.11 as SS for an SPI interface without the need to cut any solder bridge. I did a minimal project configuration. As soon as I removed the configuration option CONFIG_BT=y from my prj.conf, the pin started working.

    To be more clear, pin 0.11 can be set to high/low with the following prj.conf:

    #GPIO
    CONFIG_GPIO=y

    whereas with the following prj.conf, the pin stays always low and cannot be controlled:

    #GPIO
    CONFIG_GPIO=y
    
    #Bluetooth
    CONFIG_BT=y 
    //same behaviour regardless of value of following config options
    #CONFIG_BT_PERIPHERAL=y             
    #CONFIG_BT_DEVICE_NAME="Nordic_LBS"  

    Does this make any sense? Is there any incompatibility between GPIO and Bluetooth that I am overlooking?

    Best regards.

  • Hi,

    jbf12 said:

    Does this make any sense? Is there any incompatibility between GPIO and Bluetooth that I am overlooking?

    Yes it does make sense :) You're actually correct.

    Activating BLE will enable the network core which will allocates the pins specified here for the its UART.  atm the uart pins are hard coded, so you would have to edit the file to reconfigure the pins.

    best regards

    Jared

  • Hi Jared,

    I modified the file as you suggested, set the pins CPUNET_UARTE_PIN_RTS and CPUNET_UARTE_PIN_CTS to a different value and the issue is now gone Slight smile

    I wonder if there is any alternative to manually modifying the pins in the nrf5340_cpunet_reset.c file. Can I maybe do it from the overlay file?
    As far as I understand, this file is part of the Nordic toolchain. This means, that each developer building and running my project would have to manually edit the file. I do not really find this optimal..

    Best regards.

Reply
  • Hi Jared,

    I modified the file as you suggested, set the pins CPUNET_UARTE_PIN_RTS and CPUNET_UARTE_PIN_CTS to a different value and the issue is now gone Slight smile

    I wonder if there is any alternative to manually modifying the pins in the nrf5340_cpunet_reset.c file. Can I maybe do it from the overlay file?
    As far as I understand, this file is part of the Nordic toolchain. This means, that each developer building and running my project would have to manually edit the file. I do not really find this optimal..

    Best regards.

Children
  • Hi,

    As of right know, the edit should be done in the specific file. As you can read from the comment, the developers are aware of this non optimal solution, and I'm confident that this will change in a future release so that the pins assignment is done based on a overlay file instead of hardcoding values.

    jbf12 said:

    As far as I understand, this file is part of the Nordic toolchain. This means, that each developer building and running my project would have to manually edit the file. I do not really find this optimal..

    I totally agree with you. 

    regards

    Jared 

Related