I set up my wifly to auto connect to my access point and connect to my website when data is received at the wifly rx pin. I am NOT using the wiflyinterface library at all. On page 63 of http://ww1.microchip.com/downloads/en/DeviceDoc/rn-wiflycr-ug-v1.2r.pdf it explains the alternate functionality of GPIO4. I would like to enable the alternate functionality of GPIO4 so the mbed can monitor if the wifly is connected to the Access Point or not. Even though the manual explains how to achieve changing GPIO4 functionality I am still unsure what the bit code and command I am needing to use. For testing purposes I typed "$$$" in my terminal to enter wifly CMD mode. Next I typed "set sys iofunc 0x01", "save" and "reboot". I setup my mbed pin15 as DigitalInOut. I also set a while loop to monitor the status of pin15 and output "one" to the terminal if pin15 is high. The issue that I am having is, pin15 seems to always be high which causes "one" to be sent to my terminal. I made sure to type "leave" while connected to wiflys CMD mode to disconnect the wifly from my Access Point, but "one" is still being sent. The only time that pin15 of my mbed seems to be LOW is when I completely remove power from the Wifly I have no idea if the wiflys GPIO4 pin alternative functionality is enabled or if my mbed pin15 is setup correctly. Can anyone help me figure this out? What should I do to fix this?

Code:

#include "mbed.h"

Serial pc(USBTX, USBRX);
Serial wifi(p28,p27);

DigitalInOut w(p15);

int main() {
    
    pc.printf("Config Wifly!\r\n");

    w.input();
    
    while (1) 
    {
        wait(0.2);
        if(w.read() == 1) {
            pc.puts("one");
        }
        while(pc.readable())
            wifi.putc(pc.getc());
        while(wifi.readable())
            pc.putc(wifi.getc());
    }
}

Hi Richard,

I resisted responding, because I don't have an answer for you. I am not using GPIO4. I briefly tested GPIO6 (high when connected over TCP), but it was early in my work with the Wifly module and I haven't been back to that. But nobody else had an earlier reply for you.

I figured it out; apparently GPIO4 is not the actual pin "4". GPIO4 is actually pin "13".

After you've spent some time using GPIO4, perhaps you could drop a note if it works as expected or has any previously unforeseen effects.

David I will respond in a couple weeks, if not sooner with any news about the functionality. However, I don't for see any issues on the mbed side. The GPIO4 functionality is controlled solely by the wifly module. The mbed will be used to monitor if the GPIO4 pin is HIGH(when connected to the access point) or LOW(when not connected to an access point) and will either remain HIGH or LOW depending on the connectivity to an access point. Mind you, you will loose the use of the LED unless you trigger to turn it on and off using a command(pages 63 - 64 of the user guide explains this).

By default, those GPIO pins are tied to the respective LED functionality. If you are using a Wifly with a carrier board then there are already LEDs wired to the pins. If you have just the raw SMT module then you wire those pins to your own LEDs. You only need to set the alternate functionality flags if you want to use those pins for your own IO. The alternate functionality mask will stop the Wifly from using those pins when connection states change. By default, the status pins should already be enabled (firmware 4.00.1 anyway).

The behavior I find is that the Wifly Associated Pin (GPIO4) will go LOW after a successful connection to the Wi-Fi network (this is contrary to the documentation). If the connection fails, the pin will alternate between high and low (blink). That's using code which simply creates a DigitalIn for the mBed pin tied to GPIO4 and a DigitalOut for the mBed pin tied to an LED driver. The code then just sets ledPin = mbedStatusPin. In operation, the light is off when the device is connected and blinks when there is a problem with the WiFi configuration.

I'm running firmware 4.0. The GPIO4(actual pin I believe is 13) pin goes high when the module establishes a connection to an access point and will remain HIGH until it looses the connection to the access point, which the pin will then go LOW. What you witnessed is the same thing I witnessed when I hooked a jumper wire to the actual pin 4 of the wifly module. Are you connected to pin 13 or pin 4 of the wifly module?

Neither, it is Pin29 (GPIO4) on the RN131 raw module. I'm not using one of the carriers.

What's the exact model of your Wifly? What does your documentation say "Pin 4" is supposed to be?

It is RN-XV RN-171 I purchased my module from https://www.sparkfun.com/products/11048

The datasheet(http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Wireless/WiFi/WiFly-RN-XV-DS.pdf) explains pin 4 is GPIO8.

Ok sorry, I didn't realize the XV was the 171 with a carrier.

So yes, it looks like we are both talking about GPIO4, mine on Pin29 and yours on Pin13 (current data sheet at http://ww1.microchip.com/downloads/en/DeviceDoc/rn-171-xv-ds-v1.04r.pdf) - Pin13 is tied to the Pin9 on the 171 which is GPIO4.

You might want to reset the Wifly to factory defaults just in case the mask is messed up. That datasheet indicates that GPIO4 is the default mode for the port (as I would expect with firmware 4). Change your mBed code to just use a DigitalIn for the pin and see if that works better.

Will do. Thanks for the advice.

<<quote WiredHome>> After you've spent some time using GPIO4, perhaps you could drop a note if it works wifly expected or has any previously unforeseen effects.<</quote>>

David, it's been about a month and using this method seems to work quite well. I like the ability to have the wifly take care of the 'Internet' side of things and have the mbed process the receiving data and sending data; less code that I have to write :)