Un-bricked RN-171 WiFly module !!!

Ron Czapala

I have a couple of Sparkfun RN-XV WiFly Modules and many months ago I updated the firmware to ver 4.41 using the built-in FTP Update method.

One module worked fine but the other was bricked. I could no longer enter command mode (using $$$). I tried several approaches using the GPIO9 pin, apmode, TELNET, etc, etc.

I was about to trash it but came across the forum post by RISC:

It is not so easy but there is a procedure to regain factory reset with IO toggling GPIO9
I did it on my RN-171-EK using the 2 buttons but I had to retry many times.
You hold down the GPIO9 while pushing reset and then release reset.
After waiting a little more than One second, you press (toggle GPIO9) and you do this several times (more than 5) .
Repeat this 5 to 10 times and you should eventually see some message coming back at original speed (9600).
I has a similar issue when playing with FW updates. I tried to go down from v4.41 to V4.00 and I blocked the module. It would not respond to any command .
After several trials it eventually spitted out again some message at 9600 bauds ;=)

It did take a couple of tries but IT WORKED!!

The firmware was restored back to ver 4.00 but I went back thru the FTP update procedure and everything is working great now.

WiFly Command Reference, Advanced Features and Applications User’s Guide

The new firmware replaces the ad-hoc mode with Access Point (AP) Mode

AP mode provides several advantages over Ad Hoc mode. In AP mode:
• The module creates a soft AP network to which Android devices (smartphonesand tablets) can join. (Android devices do not support ad hoc networking.)
• The module runs a DHCP server and issues IP addresses to seven clients, which is much faster than automatic IP in Ad Hoc mode
• The WiFly module will support security in future releases, unlike ad hoc, which is an open mode
• The module supports routing between clients

sudlud

Thank you so much. This helped me after downgrading my RN171 from 4.41 to 2.36. (Because Adhoc-Mode is more stable than AP mode)

:thumb:

Ron Czapala

sudlud wrote: »

Thank you so much. This helped me after downgrading my RN171 from 4.41 to 2.36. (Because Adhoc-Mode is more stable than AP mode)

:thumb:

Interesting - what kind of issues did you experience with AP mode?

sudlud

It's similar to the problems listed in this thread:

http://www.microchip.com/forums/m782246.aspx

I'm was using Ver. 4.0, AP mode, sending data to the RN171 via UART and receiving it wireless via TCP on port 2000. Once in a while the connection broke and I did not receive any data for 1-2 seconds. For me it is vital to have a continious data stream without any breaks.

After a while I found out how to reproduce the problem:
Setup AP mode, connect with a device and receive data via TCP on port 2000 (Baud 115200)
(& continuously send data via UART to the RN171)

grab another phone/whatever and try to connect to the same AP too ( & try to open TCP 2000 afterwards)

-> the first device will lose its connection for 1-2 seconds

That's the reason for going back to 2.36 and using Adhoc mode because I didn't experience any similar problem there.

Ron Czapala

sudlud wrote: »

It's similar to the problems listed in this thread:

http://www.microchip.com/forums/m782246.aspx

I'm was using Ver. 4.0, AP mode, sending data to the RN171 via UART and receiving it wireless via TCP on port 2000. Once in a while the connection broke and I did not receive any data for 1-2 seconds. For me it is vital to have a continious data stream without any breaks.

After a while I found out how to reproduce the problem:
Setup AP mode, connect with a device and receive data via TCP on port 2000 (Baud 115200)
(& continuously send data via UART to the RN171)

grab another phone/whatever and try to connect to the same AP too ( & try to open TCP 2000 afterwards)

-> the first device will lose its connection for 1-2 seconds

That's the reason for going back to 2.36 and using Adhoc mode because I didn't experience any similar problem there.

Thanks! Good to know.