I am working to migrate my product over from the WP7603-1 to the WP7611-1 as the 7603 is now obsolete. So far in my testing mostly everything is working, except I have one minor confusion.
In the datasheet for the WP7603 it states there are 18 GPIOs that are addressable, and only 8 on the WP7611. However, when I look at the Technical Specification Guide it is not exactly clear to me which 8 GPIOs are available only to the WP7611. In fact, I see 13 GPIOs (maybe even more) on pages 149-154 in the guide.
The technical guide does specify which GPIOs are only available to Group Variant A devices (which have an MCU and ULPS capability), but the GPIOs that are not designated I assume are available on both variants, but there are still more than eight GPIOs listed here.
I could really use some clarification here on which 8 GPIOs are designated for the WP7611 if anyone else has figured this out. It’d be much appreciated too!
So that is the table I was referring to on pages 149-154 in the Product Technical Specification, so then that means all of the other GPIOs (besides 36,37,38,40, and 41) are available on the WP7611?
On the Semtech website’s product page for the WP7611 it shows 8 GPIOs available:
Currently on my WP7603 I rely on GPIOs 8, 22, 37, 35, and 42. Which I see already in my logread that exporting GPIO 37 produces an error, and GPIO 8 does not, but the LED I have connected to 8 will not activate despite the “value” file stating the GPIO is pulled high (Value is “1”).
So if all of the other GPIOs I am using are available on the WP7611 besides 37, then I’m wondering why GPIO 8 will not behave as expected… unless it’s a hardware issue
I actually checked AT+WIOCFG? yesterday after finding another post where you mention its use to determine if GPIOs are accessible from the Linux host.
I found that GPIO8 was configured to work with the Linux host, and I verified with GPIO21 (which has the same WIOCFG settings) that this works properly, as I have a green LED on GPIO21, so the steps to enable/disable it should be the same as GPIO8 (I assume), and it turns on/off by modifying “value” under /sys/class/gpio/gpio21.
I even tried removing my applications from the device, except the default apps, and I reverted the device firmware back to a stock R17 Generic firmware. Still no luck. I can control my LED on GPIO21, but the one on GPIO8 refuses to work.
I only have two modules to test with, and both are behaving the exact same. So I’m not sure at this point whether this is due to a poor hardware connection or something different in how this GPIO is implemented in the WP7611 versus the WP7603.
Looks like the GPIO Service doesn’t report any issues either, which if the GPIO wasn’t available I’d imagine it would have a similar error message to “pin not available or disabled by config”:
Yes, I downgraded from R17 to R16 to match the firmware used on my WP7603, same behavior.
Also, I don’t have any issues with exporting GPIO8 on the WP7611, it just doesn’t appear to do anything if I set its value to “1”.
Technically I’m using GPIO8 to enable a 5V rail in my device, and there is an LED attached to the rail which is supposed to turn on when it’s active. This LED still doesn’t turn on, and I have checked with a multimeter to check if there is any voltage going to it. There is none.
Also, on a side-note, I tried to install an extra WP7611 in my MangOH Red board that I have, but unfortunately with that board being obsoleted, I am unable to build a proper firmware greater than R13 which supports the WP7611 in the MangOH hardware, so that test wasn’t conclusive.
But I’ll keep pressing on, and if I find anything that works I’ll put my findings here to help the community.
Ah okay, I was trying to use the GPIO expander card that came with the board and it seemed to not be working; or at least I thought you needed an app called, “GPIOExpanderService” to use it? Which when I tried to flash that application, it threw my module into a reboot loop, until the device failed to “golden master”. So I gave up on troubleshooting the module in my Mangoh Red.
Also, same result setting GPIO8 as output via at+wiocfg:
Not quite sure why you are talking about the GPIO expander
You can put a WP7603 to mangoh red, and then measure the pin status in pin 27.
After that you can do the same for WP7611 in mangoh red board to verify.
Ah yes, this is the card I’m referring to that is outlined in the MangOH User Guides. I plugged this into my Mangoh Red, and performed the same steps to set GPIO8 as High. Then I used a multimeter to check pin 27 on this card to see if I could detect any voltage; which I did not see any changes modifying the value from 0 to 1.
Which that is when I thought I needed this GPIOExpander Service application to properly route the signal from GPIO8 on the CF3 module to pin27 on this card. Which I figured out last week after I posted that response that this card is called an “IoT card”, so I must have confused the SX1509 GPIO Expander with this “IoT card”. But regardless, I tested it out, and as I said, I did not see any voltage change on Pin27.
Also, this module is a WP7611-1, which is a low-bandwidth version of the WP7611. I assume this module is the same configuration as the standard WP7611 and it doesn’t make a difference to the GPIOs available?
Yes, I have tested with the WP7603 in the Mangoh as well, and a WP7607 that I have and both work as expected. And I can also control GPIO21 on both which is linked to a green LED.
I have 3 WP711’s. One is a loose CF3 module, and the other two are soldered to our custom PCB.
We’ve been working with the WP7607/03/08 for about five years now, and since we’ve been working to integrate the WP7611, this is the first time we’re seeing an issue like this.
From your description, the mangoh red board and WP7607/ WP7603/ WP7608 should be OK in the hardware.
Originally i think your WP7611, which tested in mangoh red board, has some problem on hardware .
But for other two WP7611 soldered to custom PCB, they also have problem, so it seems to me that this is not hardware issue.
Yeah, I’m scratching my head on this too, trying to determine if it’s hardware related or not. I just got this from one of my colleagues, so I’ll have to check with them if they can contact the distributor and see if we can get some additional samples.
Thank you again for all of your help! I really appreciate it!
Darn, okay. Let’s see what my colleague can figure out on our end, and I’ll try to obtain another fresh module to test with, and I’ll report if we have any success.
