• AVR Freaks

Hot!DO NOT use RN171 with updates from Microchip.

Page: 12 > Showing page 1 of 2
Author
WiSpher
Starting Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2014/02/20 14:21:57
  • Location: 0
  • Status: offline
2014/02/20 14:56:44 (permalink)
4.2 (5)

DO NOT use RN171 with updates from Microchip.

Hi All,
 
After weeks (months) waiting for response from Microchip "support" regarding serious issues in RN171 module (watchdog resets) with no answer, we have decided to warn all of you here.
 
DO NOT USE firmware updates from Microchip !!!! and DO NOT use RN171 for new designs.
Why ?
Beginning from version 4.0 the firmware is completely unstable. 
Number of watchdog resets and situations when it is 100% reproducible is only rising.
We have tested all versions available since October 2013 until now on the FTP server and the conclusion is only one - every next version is worse than the previous one. 
Below you can find the logs with some example and related notes from the ticket reported to microchip support as an example of their (in)competence …
It looks like Microchip has bought Roving to kill their great product … it’s pity.
We really miss old good times where Roving guys have reacted in a few hours and were really helpful.
That’s all –we start now to re-design our almost ready product for new Wi-Fi module coming from Microchip competitor.
 
Cheer,
WiSpher Team
 
Logs:
wifly-EZX Ver: 4.41 Build: r1057, Jan 17 2014 10:23:54 on RN-171
MAC Addr=00:06:66:71:38:08
*READY*
*ERR WATCHDOG: 3210*
AP mode as WiSpherT on chan 1
Listen on 2000
DHCP Server Init
Connect FAILED
 
wifly-EZX Ver 4.00.1, Apr 19 2013 11:47:16 on RN-171
MAC Addr=00:06:66:71:38:08
*READY*
*ERR WATCHDOG: 6CC9*
 
DHCP wifly-EZX Ver 4.00.1, Apr 19 2013 11:47:16 on RN-171
MAC Addr=00:06:66:71:38:08
*READY*
*ERR WATCHDOG: 2ED7C*
 
wifly-EZX Ver: 4.40 Build: r1018, Nov 25 2013 14:45:13 on RN-171
MAC Addr=00:06:66:71:50:13
*READY*
*ERR WATCHDOG: FFFFFFFF*
<4.41>
<4.41> show stats
Conns=0, WRX=0/0, WTX=0/0, RTRY=0, RTRYfail=0
 URX=11, UTX=319, RXdrop=0, RXerr=0,
FlwSet=0, FlwClr=0
 TX-UDP=0, netbufs=0, evt=0, adhoc_lost=0
Boots=2, Wdogs=9,TXon=1
 
Ticket Story:
Created 13.11.2013

[lang="en-us"]Dear Support Team,[lang="en-us"]
I have sporadic watchdog resets in the RN171 module (Ver 4.00.1, Apr 19 2013 11:47:16). 
The full configuration of the module has been attached.
Module is configured for the UDP broadcast and it goes sleep after 7 sec. for 30sec.
Sporadically in the time module shall wake up I can see on the serial port following information:

[lang="en-us"]wifly-EZX Ver 4.00.1, Apr 19 2013 11:47:16 on RN-171
[lang="en-us"]MAC Addr=00:06:66:71:38:08
[lang="en-us"]*READY*
[lang="en-us"]*ERR WATCHDOG: 6CC9*
[lang="en-us"]Auto-Assoc Siudy_NET chan=1 mode=MIXED SCAN OK
[lang="en-us"]Joining YYYYYY now..
[lang="en-us"]Associated!
[lang="en-us"]DHCP: Start
[lang="en-us"]DHCP in 1919ms, lease=1814400s
[lang="en-us"]IF=UP
[lang="en-us"]DHCP=ON
[lang="en-us"]IP=192.168.2.100:2000
[lang="en-us"]NM=255.255.255.0
[lang="en-us"]GW=192.168.2.1
[lang="en-us"]
After such error the module doesn't send any more UDP broadcasts. Moreover it goes to sleep but then wakes up not after full wake up time (30 sec). but after some random time (usually <20sec).
The issue is for sure application (HW) independent. I can observe the same issue with the evaluation board RN174p and with the final application HW.
The "
[lang="en-us"]*ERR WATCHDOG: 6CC9*" appears also with different hex codes at the end (see attached file) but this seems to be constant for every module.
[lang="en-us"]

I have seen on the web page that the firmware 4.40 has been released (release note is available) but the firmware file is not present on the FTP server. When I can expect the firmware to be available on the FTP ?
I will appreciate your feedback as soon as possible.
Kind Regards,


Update 1 : 11/15/2013 06:56 AM
Dear Support Team,
In the meanwhile we have found firmware 4.40 on the FTP drive (in the directory beta) and decided to check if the issue with WDG resets is present also there.
Unfortunately it appears also with this firmware version.
Reading the status of the module over show stats command give us an error rate about 15% (e.g. for the 100 boots we have got 15 WDG resets).
We will really appreciate your feedback. The issue is that in our application we have assumed we can rely on known wake up timer value. But in case the module runs in WDG reset, the time schedule is completely destroyed.
Thanks for your help in advance 



Response 1: 
11/21/2013 03:42 AM 
Hi,
I have to ask in the factory please allow some time for the response.
In the meantime. I want you to test another module.. maybe there is something wrong in the hardware.Please let me know the results.
Best regard
s,

 
Upadte 2: 11/21/2013 11:54 AM - since then no more response but new (worse) firmware release on the FTP server
Dear Xxxx,
Thanks for your response. 
I am pretty sure it cannot be the hardware. I have the same issue on the original evaluation board and 2 more application prototypes (like stated in original description). It seems to be definitely firmware bug. I have tested one of affected modules with older firmware version and the WDG reset doesn't occur.
Kind  Regards,

 
#1

23 Replies Related Threads

    NKurzman
    A Guy on the Net
    • Total Posts : 17924
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re:DO NOT use RN171 with updates from Microchip. 2014/02/20 19:26:45 (permalink)
    5 (1)
    Do you have a Microchip F.A.E.? (Field Application Enginner)
    if you are in the U.S. and are a read Company, the answer is Yes
    #2
    WiSpher
    Starting Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2014/02/20 14:21:57
    • Location: 0
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/02/21 16:08:32 (permalink)
    0
    Hi,
     
    Thanks a lot for the fast response. Looks like forum moderation reacts faster than technical support getting information about bugs in your products.
    Anyhow: now we do not have FAE . We are group of enthusiastic located in Europe and earning many in automotive embedded world. WiSpher is our hobby, which supposed to be in the near future kind of startup.
    And that's our problem. As long as we cannot tell about millions of pcs which we could sell in the future no one take us serious. That's pity. But that’s the life. 
     
    Cheers,
     
    WiSpher 
     
    #3
    NKurzman
    A Guy on the Net
    • Total Posts : 17924
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re:DO NOT use RN171 with updates from Microchip. 2014/02/21 16:15:42 (permalink)
    5 (1)
    Sorry this is a User Forum.  I am not the Moderator.
    You can try your Electronic Suplier and see if they can help or suggest how to get help.
    I am not sure how they do it in Europe.
    Did you try calling Microchip with the Ticket Number?
    #4
    WiSpher
    Starting Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2014/02/20 14:21:57
    • Location: 0
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/02/21 16:24:50 (permalink)
    0
    Hi,
     
    I am sorry ....  about this "moderation" above .....
    In Europe it works in the same way like in US. (I know that from my normal work).
    We did try to contact microchip but never overcome first level support. Means - no real help only promisses ...
    And from some reason I do not want to use my contacts from the regular job over distributors , etc.
    We thought that in case of real technical issues the source of information doesn't metter but looks like only problems reported by big customers are important. 
    I will try to catch someone from Microchip next week on Embedded World in Nürnberg - maybe this will help.
     
     
     
    #5
    ~Maddy~
    Senior Member
    • Total Posts : 153
    • Reward points : 0
    • Joined: 2012/08/03 21:06:18
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/03/08 00:48:38 (permalink)
    0
    WiSpher,
    Really there are very less information available for WiFly troubleshooting and all.
    I am also trying to update firmware 4.40 but not able to find steps or guide for that.
    #6
    stevestrong
    Starting Member
    • Total Posts : 21
    • Reward points : 0
    • Joined: 2013/12/12 02:41:09
    • Location: 0
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/03/10 10:32:50 (permalink)
    0
    here you can find some info about updating over ftp:
    http://www.microchip.com/...ree=true&m=765256#
     
    #7
    jyaron
    Super Member
    • Total Posts : 392
    • Reward points : 0
    • Joined: 2003/11/07 12:43:15
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/04/16 15:59:30 (permalink)
    0
    Does the RN171 FW v4.40 experience watchdog resets if UDP broadcast is disabled?
     
    #8
    ~Maddy~
    Senior Member
    • Total Posts : 153
    • Reward points : 0
    • Joined: 2012/08/03 21:06:18
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/04/16 20:36:52 (permalink)
    5 (1)
    jyaron
    Does the RN171 FW v4.40 experience watchdog resets if UDP broadcast is disabled?
     


    Well, I am not sure about this but right now seems firmware upgrade to v4.41 is also not reliable. It throws many watchdog error.
    #9
    mhsprang
    New Member
    • Total Posts : 1
    • Reward points : 0
    • Joined: 2014/05/23 01:42:46
    • Location: 0
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/05/23 01:58:33 (permalink)
    4.5 (2)
    I experience similar problems with the RN-131 modules. And this is no hobby project. In our production process, we test our product and routinely update the RN-131 to the latest version. Suddenly all updates failed. It turned out that we received boards with RN-131 on them that were loaded with 4.00 firmware. Before that, V2.38 was loaded in the RN-131.
     
    Our firmware update process comprises the following steps:
    * Erase the existing config file on the RN-131
    * use "ftp cu" to clear the file system and download new firmware (V4.41 in this case, wee NEED security)
    After some serious testing with appr. 20 different RN-131 modules I concluded the following:
    After a successful ftp download, the module reboots and starts outputting *CRASH* messages at 115200 baud.
    Some modules continue to do this forever and cannot be recovered, not even with the recovery process using GPIO9.
    The modules that CAN be recovered with the GPIO9 procedure appear to boot normally, but at 115200 baud and do not respond to the $$$ sequence.
     
    Other modules remain in the *CRASH* state for 30s to 5min and then successfully reboot and come up with the normal messages and one single *WATCHDOG* message at 4800 baud. After that, they can be configured as usual and work as usual, although customers report unstable connections every now and then.
     
    I have reported this to Microchip support but received no usable answer.
    We have now appr. 1600 products using the RN-131 sold worldwide and many of our clients are desperately waiting for V4.41 because of the offered AP encryption.
    Because of these problems, we halted our production and we revoked the last firmware update from our website, waiting for a solution from Microchip.
     
    It is really beyond my comprehension that this is not solved or at least responded to within a day or 2! This is costing us a lot of time and money right now!!
    #10
    ~Maddy~
    Senior Member
    • Total Posts : 153
    • Reward points : 0
    • Joined: 2012/08/03 21:06:18
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/06/02 20:20:24 (permalink)
    3 (2)
    I had worst experience ever with microchip.
     
    I order few Wifly modules from Mouser and few from Microchip-Direct. They were with 4.00 version so I did update on them and some of them behaving weird after update and even I am not able to downgrade to 4.00 after that then I generated Ticket for support but they were not able to resolve the issue and they said they will give replacement and for that I have to contact local Microchip office. So I contact local guy and gave these module for replacement after one month they reply back it's your responsibility that you did firmware update we will not replace this or repair it.
     
    I really wonder their firmware 4.00 has bug that is why we need to update 4.41 and if we do then it's our responsibility GREAT MICROCHIP !
    #11
    E1024
    New Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2014/05/05 05:23:27
    • Location: 0
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/06/03 04:03:44 (permalink)
    4 (2)
    v4.00.1 has a bricking problem if it gets brownout too much, otherwise the functionality is at least satisfactory.
    The new v4.41 is another story (tested with ten RN-171 modules!): cannot associate with most of the routers, all the commands regarding network name and soft ap / access point switching need to be rewritten, and even then it does not behave the same way as before. More *CRASH* messages also. No use in the added security and the fix for the bricking problem if most of the firmware got actually worse...
    #12
    gentled
    New Member
    • Total Posts : 4
    • Reward points : 0
    • Joined: 2014/07/18 02:21:16
    • Location: 0
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/08/08 02:41:30 (permalink)
    0
    I too am having similar problems with RN171 flipping into a mode where the UART transmits at 115200baud, but wont react to any commands (specifically $$$ to get it into command mode!). Attempts to enter AP (to use the config page to do a factory reset) fail, as does the 5 or 7 press hardware reset. As the UART output works you can see something of what is happening, the output is littered with *CRASH* and *WATCHDOG* errors. Basically it takes so long to press the hard reset button 5 times that the unit Watchdogs or crashes first!
     
    I now have a large number of "bricked" RN171s, did anyone get any response to the instability issues discussed here?
    #13
    ~Maddy~
    Senior Member
    • Total Posts : 153
    • Reward points : 0
    • Joined: 2012/08/03 21:06:18
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/08/08 02:47:06 (permalink)
    0
    gentled
    I too am having similar problems with RN171 flipping into a mode where the UART transmits at 115200baud, but wont react to any commands (specifically $$$ to get it into command mode!). Attempts to enter AP (to use the config page to do a factory reset) fail, as does the 5 or 7 press hardware reset. As the UART output works you can see something of what is happening, the output is littered with *CRASH* and *WATCHDOG* errors. Basically it takes so long to press the hard reset button 5 times that the unit Watchdogs or crashes first!
     
    I now have a large number of "bricked" RN171s, did anyone get any response to the instability issues discussed here?


    Which version you have on RN171? If you have v4.00 and you are not able recover by hardware reset 5-7 time GPIO press then I would like to say it will not recover any how. I have faced similar issue. If you have v4.41 then you have chance to recover the module to factory programmed version.
    #14
    gentled
    New Member
    • Total Posts : 4
    • Reward points : 0
    • Joined: 2014/07/18 02:21:16
    • Location: 0
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/08/08 04:51:03 (permalink)
    0
    The unrecoverable units are all 4.0. Thanks for the clarification. Given the *CRITICAL* and *WATCHDOG* mesages during the attempt to GPIO9 reset this makes sense.
     
    Have you any idea how the unit got into this state? Is there some things that should be avoided in UART communication or hardware design?
     
    All units we have purchased in the UK are pre-programmed with 4.0. You say 4.4 is recoverable, but is it any less likely to fail? I cant tell my customers to press GPIO5 times, doesn't look good :-)
     
    Thanks for the support.
    James
    #15
    ~Maddy~
    Senior Member
    • Total Posts : 153
    • Reward points : 0
    • Joined: 2012/08/03 21:06:18
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/08/08 04:58:39 (permalink)
    0
    gentled
    The unrecoverable units are all 4.0. Thanks for the clarification. Given the *CRITICAL* and *WATCHDOG* mesages during the attempt to GPIO9 reset this makes sense. Have you any idea how the unit got into this state? Is there some things that should be avoided in UART communication or hardware design? All units we have purchased in the UK are pre-programmed with 4.0. You say 4.4 is recoverable, but is it any less likely to fail? I cant tell my customers to press GPIO5 times, doesn't look good :-) Thanks for the support.James


    One major point is if you operate module in brown out range. But I was confident about my hardware that it never goes into that state.
    So for my case I got my module brick when doing upgrade.

    Which board you are using when you are doing this GPIO toggle?
    #16
    gentled
    New Member
    • Total Posts : 4
    • Reward points : 0
    • Joined: 2014/07/18 02:21:16
    • Location: 0
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/08/08 09:31:46 (permalink)
    0
    The prototypes all use RN171XV - a little carrier PCB for easier prototyping. Final design will use the native RN171 onto a custom board. The prototype consists of various "modules" culled from other products we make mounted together on a plate. The key components are a controlling PIC, a RS232 level shifter and a 5 to 3V3 PSU which delivers 30mVpp of noise on the rail.
     
    The hard reset involves holding GPIO9 high at power-up for 1-2second, low for 1-2seconds, then repeat this 4 or 6 times for increasingly "severe" boots. The most severe is nothing left on flash everything from ROM. I think with every cycle of GPIO9 the lamps on the RN171XV flicker a little more, but if a watchdog happens the unit jumps out into "normal" mode so you never get to the end of the 20-30second reset process.
     
    We have ordered more units for one last try with 4.41 code.
     
    Thanks for the support!
    James
    #17
    ~Maddy~
    Senior Member
    • Total Posts : 153
    • Reward points : 0
    • Joined: 2012/08/03 21:06:18
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/08/08 15:53:45 (permalink)
    0
    gentled
    The prototypes all use RN171XV - a little carrier PCB for easier prototyping. Final design will use the native RN171 onto a custom board. The prototype consists of various "modules" culled from other products we make mounted together on a plate. The key components are a controlling PIC, a RS232 level shifter and a 5 to 3V3 PSU which delivers 30mVpp of noise on the rail. The hard reset involves holding GPIO9 high at power-up for 1-2second, low for 1-2seconds, then repeat this 4 or 6 times for increasingly "severe" boots. The most severe is nothing left on flash everything from ROM. I think with every cycle of GPIO9 the lamps on the RN171XV flicker a little more, but if a watchdog happens the unit jumps out into "normal" mode so you never get to the end of the 20-30second reset process. We have ordered more units for one last try with 4.41 code. Thanks for the support!James

    You have nothing to worry if you are going to use native nodule. As native module you can ask microchip to come up with 4.41 and you have no worries about being brick.

    Although faces many issue still RN171 is the best module compare to all other.
    #18
    Miroslav Suchý
    New Member
    • Total Posts : 20
    • Reward points : 0
    • Joined: 2014/09/23 13:50:41
    • Location: 0
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2014/10/06 22:18:21 (permalink)
    0
    What are the alternatives to RN{171,131}?
    #19
    rodri16
    New Member
    • Total Posts : 1
    • Reward points : 0
    • Joined: 2015/03/11 04:03:08
    • Location: 0
    • Status: offline
    Re:DO NOT use RN171 with updates from Microchip. 2015/03/11 04:13:23 (permalink)
    0
    After updating 4.41 version and putting RN-XV 171 in AP mode following 
    I get *CRASH* when I want to connect to it!!
     
    wifly-EZX Ver: 4.41 Build: r1057, Jan 17 2014 10:23:54 on RN-171
    MAC Addr=00:06:66:71:d7:ea
    *READY*
    AP mode as WiFly-EZX-ea on chan 1
    Listen on 2000
    DHCP Server Init
    *CRASH* #=7,40018cd0
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5