GPIO Problems - GPIO35 does not work on WP7504


I know this topic has been described before and on the legato forum. I struggled with GPIO42 until Release 13. For those that have not seen this problem, GPIO42 did not work on the WP7504.

root@swi-mdm9x15:~# echo 42 > /sys/class/gpio/export
sh: write error: Operation not permitted

Loading Release 13 on the WP7504 fixed the problem.

Now I see this with GPIO35. GPIO35 is important because it is one of the pins (WP_GPIO_8_lvl, Pin 15) on Mangoh Red.

root@swi-mdm9x15:~# echo 35 > /sys/class/gpio/export
sh: write error: Operation not permitted

Anybody else see this problem? I love the platform, but the little things are killing me.


Hi Chuck,
It seems like the unit you have didnt go through proper PRI or was a very early sample.
By default this GPIO must accessible through the app processor. Since you dont have the proper PRI setting, please do the following:
a. Enter the following AT command ( you cna enter AT comand mode by minicom -E /dev/ttyAT):

b. reset the unit
c. now the echo command should work

Let me know if you run into any issues.



Also, if you run AT+WIOCFG? it will give list of all gpios and their configuration.
If it is set to 16, then the app processor has access to the gpio.


You are correct Ashish,
I did this previously on other chips but I forgot about this on a new chip. I almost never think about that “AT” commands. I had a problem that this would not fix on GPIO42, but it fixes my problem here just fine. Thanks for the reminder. I will add that to my initialization process for chips. I guess I may be able to write some code that sends “AT” commands blindly to /dev/ttyAT.

And so far I’ve not found any problems with the RED itself. I use WP7504 which I purchased so that does not go thru your process. I just about ready to put my Power Monitor on the board to see where I stand.


Let us know your power meter results. Note that on our side, we found the following:
a. 50ua average current in lowest power mode. You can power through USB connector with no board mods for mode a.
b. this dropped to 5-10ua, when we bypassed the battery charger. basically, DNI R827 and R820 and populate 0R at R826.
For mode b, or the lowest power mode, the power 3.4-4.3V is provided through CN802.

Here is the command to put the device in ULPM timer mode:
echo 600 > /sys/module/swimcu_pm/boot_source/timer/timeout
echo 1 > /sys/module/swimcu_pm/boot_source/enable


Now that I have GPIO35 fixed and operating correctly, I’ve discovered another oddity in my testing. IOT_GPIO3/WP7504 GPIO7. Initially at power up the output is high. According to what I can find in the WP75xx data sheet and the Qualcomm documentation, it should be like the other pins and there should not be any active drive on it. Unfortunately, I’m not sure where inside the chip the I/O is initially configured, but my assumption is that is not done by the application processor but by something else. Do you know if there is a pull up somewhere in the design that causes the pin to start out high, and then after about 6 seconds, go low? I need to figure out if this is permanent or something that might change in the future.


There is no internal resistor pull up on the module. I’ll need to check why it changes state.


Hi chuck, you are right. The GPIO7 from WP85 also shows the same issue. There is not any pull up and it is the issue with that specific GPIO pin as e.g. GPIO13 doesn’t have that problem.
We will contact our WP guys and give you an update. Thanks for the info.