WIZ107SR - Scrambles its own config

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…

image

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?

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!).

More update :slight_smile:

image

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

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.

image

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…

Hi FalconFour,

I think, below links will help you.

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.