WIZ107SR - Scrambles its own config

Question

Here’s a fun one for you. It’s a major thorn, as it’s affecting nearly all the deployed devices in this config - over time. They start off working fine, but they eventually (anywhere from 30 minutes to a month later) end up bricked. I took a “brick” back for diagnosis, and found that it did indeed produce serial data output. Not at the defined 9600 baud, but instead back at 57600 baud. Except it wasn’t completely factory-reset… it was still using DHCP, and that worked fine. It forgot who to connect to (so it didn’t establish a connection). But more importantly… it set its own random-garbage “search key”, so it doesn’t respond to ConfigTool scans. I managed to get it into serial command mode by holding the HW_TRIG pin low during power-up (indicated by “LGHWSWITCHOK”). Then, I asked it for its config details… Nasty. So, what caused this random memory store corruption? Is there a way to keep this thing from ever changing/resetting its config? Should the HW_TRIG pin be tied high? We only use 3 pins - Rx, Tx, Reset (floating normally, pull-down to activate; noise reduction by adding 0.1uF cap between VCC and Reset). No flow control, no other pins. This is the TTL (3.3v) version - though driven by 5v logic (an unfortunate compromise we really couldn’t avoid, but seems to work). Do the unused pins need to be tied somewhere?

FalconFour · Answer

Well… (sigh… support) I hope I fixed it. I designed a little circuit board that sits on top of the module with a DC-DC converter to take 5V input and convert to 3.3v on the module (instead of down the external data cable), hopefully cleaning up the power. Also added pull-ups to the nReset, HW_TRIG, and nFac_Rst pins (4.7k to combined HW_TRIG and nFac_Rst; 10k to nReset) just to be absolutely sure they don’t drift downward at any point during use. “nReset” is pulled-down by MCU periodically if it’s not getting any data flow, so that should ensure reliability… Just need to be sure the dang thing never gets a spontaneous flair to scramble its config like this at any time in the future… these things get deployed to stations where an expensive truck call is necessary to service them, so they need to stay perfectly stable. Hopefully this little “wiznet pampering board” works out… just really wish the module were designed with these kinds of stability parts built-in (and that the thing didn’t run on 3.3v!).

FalconFour · Answer

More update The modules (yep, multiple! Now we’re starting to work on refurbishing them) forget their MAC address when this happens. This module had a scrambled config as well, and most of its config variables were set to FF (255). Here, you can see, the MAC address was set to FF:FF:FF as well. Of course, this persists over a “factory reset” and I don’t currently know any way to repair it. Can someone offer some help/advice on repairing this to return them to like-new status? I think this problem had its roots in poor supply power quality / brownouts… now we’ve fixed that and are shipping modules with a “pamper board” attached with a 3.3v regulator on-board (supplied with 5v down the line). So it shouldn’t be a problem in the future, but we’ve got a lot of modules in the field to repair/refurbish… edit: Abridged version of the complete session log from this module: LGWIZ107SR:VER4.06:STARTED LGHWSWITCHOK LGSEGCP:TCP:STARTED LGSEGCP:UDP:STARTED MC MC00:08:DC:FF:FF:FF PW [module went unresponsive, rebooted] OP OP255 IM IM255 ST STATMODE No PHY Link! PHY will be initialized again DD DD255 CP CP255 LP LP65535 RH RH▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒k▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ RH RH▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒k▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ No PHY Link! PHY will be initialized again DH DHWIZ107SR-52f661 IT IT65535 VR VR4.06 MN MNWIZ107SR No PHY Link! PHY will be initialized again FR LGWIZ107SR:VER4.06:STARTED LGHWSWITCHOK LGMAC:00.08.DC.FF.FF.FF LGGW:192.168.11.1 LGSN:255.255.255.0 LGIP:192.168.11.2 LGSEGCP:TCP:STARTED LGSEGCP:UDP:STARTED

FalconFour · Answer

Another update. Fascinating case, here… “INPUT FIRST MAC?” No idea what format to input it in, so I tried just with hex digits (53:7B:A4). It spat back jibberish, I hit Enter… and it took “00:00:01” as its MAC. I’m thinking these modules have a serious problem with EEPROM stability… update: both of these modules now test OK, though they are now stuck with one FF:FF:FF address and one 00:00:01 address… which is fine, since they end up being on a very small NAT network. So, hey, it works…

irina · Answer

Hi FalconFour, I think, below links will help you. WIZ107SR need to factory reset module... WIZ107/108SR Hi, Grogster You can recover your WIZ107SR module using factory firmware in below link. At this time, you have to program the flash memory using the WIZISP tool for W7100A MCU. Download the WIZISP program via the link below and try to recover your product. http://www.wiznet.io/wp-content/uploads/wiznethome/Chip/W7100A/Utility/WizISP_Program2.1.1_and_Guide1.0.zip Below link will help you for using WIZISP tool. I’ll guide you through a simple product recovery steps. Conn… Change W7100 Chip For W107SR module WIZ107/108SR After you have set the firmware on the board, check to see if the ‘Input MAC address’ is printed via serial(UART). At this time, you can enter the MAC address using WizMACTool mentioned in the previous post or you can type it directly in the following command format. MC00:08:DC:xx:xx:xx[CR][LF] If the MAC address is input correctly, the network setting information output from the serial can be checked. If the device is not detected on the network by configuration tool (search), please check… MAC address and product setting information of WIZ107SR module are stored in data flash. If you want to enter the MAC address again, connect to the module with WIZISP tool and select ‘data flash’ and erase it. You can download the WIZ107SR ‘Boot + App’ binary file via the link above and know how to enter a new MAC address.