Binding WP_GPIO_5 (GPIO36)


Hello all,

I’m having some trouble binding WP_GPIO_5_wakeable in my app.

Screenshot taken from MangOH Red schematics page 2.

My app definition and component definition are as follows:



    le_adc = ${LEGATO_ROOT}/interfaces/modemServices/le_adc.api
    le_digital1 = ${LEGATO_ROOT}/interfaces/le_gpio.api
    le_digital2 = ${LEGATO_ROOT}/interfaces/le_gpio.api
    le_iot1 = ${LEGATO_ROOT}/interfaces/le_gpio.api
    le_iot2 = ${LEGATO_ROOT}/interfaces/le_gpio.api
    le_iot3 = ${LEGATO_ROOT}/interfaces/le_gpio.api
    le_iot4 = ${LEGATO_ROOT}/interfaces/le_gpio.api
    le_dht = ${LEGATO_ROOT}/interfaces/le_gpio.api
    le_posCtrl = ${LEGATO_ROOT}/interfaces/positioning/le_posCtrl.api
    le_pos = ${LEGATO_ROOT}/interfaces/positioning/le_pos.api
    le_cfg = ${LEGATO_ROOT}/interfaces/le_cfg.api
    le_spi = ${LEGATO_ROOT}/interfaces/le_spi.api

    /sys/devices/i2c-0/0-0068/iio:device0/in_accel_x_raw    /sys/devices/i2c-0/0-0068/iio:device0/
    /sys/devices/i2c-0/0-0068/iio:device0/in_accel_y_raw    /sys/devices/i2c-0/0-0068/iio:device0/
    /sys/devices/i2c-0/0-0068/iio:device0/in_accel_z_raw    /sys/devices/i2c-0/0-0068/iio:device0/
    /sys/devices/i2c-0/0-0068/iio:device0/in_accel_scale    /sys/devices/i2c-0/0-0068/iio:device0/
    /sys/devices/i2c-0/0-0068/iio:device0/in_anglvel_x_raw  /sys/devices/i2c-0/0-0068/iio:device0/
    /sys/devices/i2c-0/0-0068/iio:device0/in_anglvel_y_raw  /sys/devices/i2c-0/0-0068/iio:device0/
    /sys/devices/i2c-0/0-0068/iio:device0/in_anglvel_z_raw  /sys/devices/i2c-0/0-0068/iio:device0/
    /sys/devices/i2c-0/0-0068/iio:device0/in_anglvel_scale  /sys/devices/i2c-0/0-0068/iio:device0/
    /sys/devices/i2c-0/0-0076/iio:device1/in_temp_input     /sys/devices/i2c-0/0-0076/iio:device1/
    /sys/devices/i2c-0/0-0076/iio:device1/in_pressure_input /sys/devices/i2c-0/0-0076/iio:device1/



sandboxed: true
start: auto
version: 0.1

  sensorToCloud = ( avPublisher sensors )
  spiService = ( $LEGATO_ROOT/components/spiService )

    ( sensorToCloud spiService )
  faultAction: restart


  sensorToCloud.sensors.le_adc -> modemService.le_adc
  sensorToCloud.sensors.le_digital1 -> gpioExpanderServiceRed.mangoh_gpioExpPin3
  sensorToCloud.sensors.le_digital2 -> gpioExpanderServiceRed.mangoh_gpioExpPin4
  sensorToCloud.sensors.le_iot1 -> <root>.le_gpioPin42
  sensorToCloud.sensors.le_iot2 -> <root>.le_gpioPin13
  sensorToCloud.sensors.le_iot3 -> <root>.le_gpioPin7
  sensorToCloud.sensors.le_iot4 -> <root>.le_gpioPin8
  sensorToCloud.sensors.le_dht -> <root>.le_gpioPin36
  sensorToCloud.sensors.le_posCtrl -> positioningService.le_posCtrl
  sensorToCloud.sensors.le_pos -> positioningService.le_pos
  sensorToCloud.sensors.le_spi -> spiService.le_spi
  sensorToCloud.avPublisher.le_avdata -> avcService.le_avdata 


The app appears to hangup with this message:

LE_FILENAME InitPool() 303 | Memory pool name 'framework.hashMap_refle_dht_ClientHandler' is truncated to 'framework.hashMap_refle_dht_Cli'

Hopefully I’m not missing something obvious here. Any help is greatly appreciated.


This pin is SYSFS only and needs to be configured via a AT command


You will need to export it and use /sys not legato API


Thank you @gregnietsky, I’ll give this a try. Do you know anything about binding GPIO_0_EXP and GPIO_1_EXP on the MT7697 module? I haven’t seen any examples for this.


The GPIO_*_EXP pins you reference are connected directly to the mt7697 so there is no convenient out of the box way to control those from Linux. Technically it would be possible to write a gpiochip kernel driver that talks over SPI or the UART to the mt7697, but we haven’t done that. Is there a reason why you need those specific GPIOs controlled by Linux?


Thanks for the reply @dfrey. We were previously unaware of this constraint. We’ll simply use some different GPIO pins in that case. Is there any documentation showing which pins will require additional driver work? Or should we just assume any I/O on separate chip will require some extra work?


Choose GPIOs that come directly from the WP module and you should be pretty safe. It’s also possible to write code for the MT7697 that uses the GPIOs you mentioned, but that will complicate your software design a bit.


Thanks @dfrey, we’ll keep this mind going forward.


@dfrey Is there a nice way to attach a callback function to a SYSFS GPIO value change? It was extremely convenient to use le_gpio_AddChangeEventHandler for this purpose but obviously this is not an option for GPIO pins that are SYSFS only.


I’m also interested if this is possible.

If you have any spare (non SYSFS-locked) GPIO pins you could connect the signal to both GPIO36 and some other GPIO for monitoring in an app, enabling you to use le_gpio_AddChangeEventHandler.

A bit wasteful, I know - but it works.


@Raf Unfortunately we’re stuck using these pins. The callback and event loop method is a very elegant so I would like to preserve it if possible.


Hi @nick,

The API of interest is interfaces/le_gpio.api in the Legato project. The GpioExpanderService for mangOH Green and mangOH Red implement this API for the sx1509 GPIO expanders on the mangOH boards. There is a sample program in Legato which demonstrates the use of the WP GPIOs using the GpioService.

Let me know if you have any questions after reading through that sample.


Hey @dfrey,

That appears to be working. Thanks for the support.


Hello all,

We had le_gpioPin36 and le_gpioPin38 working using gpioService, however as of this morning only le_gpioPin38 is working. We get the following message for le_gpioPin36: Skipping starting GPIO Service for Pin 36 - pin not available or disabled by config. What config does this refer to, and what would cause the pin to be unavailable?


Hello again, I believe this may be a false alarm. I’ll report back tomorrow.


Confirmed this was a false alarm.