devices reset and loses input output parameters

[atilim07]

device resets
device name
ports are corrupted
loses input output parameters

[nielsonm236]

The only time I've seen this is when the power supply is not adequate to prevent the built-in power reset from triggering intermittently. Intermittent resets, if they occur during writes to the EEPROM, will cause the corruption you describe. So a little more information is needed to help determine the source of the resets.

• Are any relay connected? If yes, check if the device remains stable with no relays. If it is stable without relays, then the suspect should be the power system. In this case it is likely that relay switching current is glitching power to the module.
• If no relays are connected and you are having this problem, make sure the power supply is providing between 5.0 to 5.5 volts, and is able to supply a minimum of 500ma to the module.
  With answers to the above I can give you some next steps.
  Mike

[nielsonm236]

Had any luck with the suggestions?

[gabortamasko]

Hi, the same occured. Please help.
I use 4 pins as output and actuate (via n ch mosfet) a 4 port relay.
Power delivery is sufficient, added few 1000uF caps.
The relay board is a 12V board, max draw is 200mA when all relays are on.

Still, if I change any output state, that would pull a relay via n-mosfet the board behaves crazy, pulls those 4 outputs high, and forgets pin type settings like output and input, invert state boot state and timer settings.
It does not forget any other settings tho...
None of the output do have "retain" settings, so there should be no eeprom write by my logic... except if any problems do occur and it was logged localy.

BUT, and heres is the but. If I setup the system again, there is a 25% chance, that from there on it will work fine for days.
No switching problems whatsoever.

Here is some logs for you:

Link Error Statistics
31 0000001099
32 0000000435
33 0000000000
35 0000000000

0000000083 Dropped packets at the IP layer
0000000329 Received packets at the IP layer
0000000199 Sent packets at the IP layer
0000000002 Packets dropped due to wrong IP version or header length
0000000000 Packets dropped due to wrong IP length, high byte
0000000000 Packets dropped due to wrong IP length, low byte
0000000000 Packets dropped since they were IP fragments
0000000000 Packets dropped due to IP checksum errors
0000000000 Packets dropped since they were not ICMP or TCP
0000000000 Dropped ICMP packets
0000000000 Received ICMP packets
0000000000 Sent ICMP packets
0000000000 ICMP packets with a wrong type
0000000000 Dropped TCP segments
0000000249 Received TCP segments
0000000202 Sent TCP segments
0000000000 TCP segments with a bad checksum
0000000000 TCP segments with a bad ACK number
0000000001 Received TCP RST (reset) segments
0000000004 Retransmitted TCP segments
0000000000 Dropped SYNs due to too few connections avaliable
0000000000 SYNs for closed ports, triggering a RST

[nielsonm236]

This is very puzzling. I don't see anything particularly wrong in the Link Error stats except stat 33 should have a "6" in the fifth digit from the right. That digit would indicate the revision level of the ENC28J60. The fact that it is reporting "0" is odd ... not sure how that could happen ... and wondering if it is a clue.
Since I haven't seen anyone else report this kind of problem unless there was a power issue, let me ask a few questions:

1. Since the relays run at 12V, you must have a separate 5V power supply for the Network Module. Is that correct?
2. Is the 5V supply derived from the 12V supply used for the relays, perhaps with a 5V regulator?
3. How often do you switch a relay?
4. Are you switching relays with Browser / REST commands? Or are you using MQTT?
   Let me know the above and I will think some more on this.
   Mike

[nielsonm236]

One more question: Please let me know the part number for the n-mosfet you are using.
Thanks

[gabortamasko]

BSP308 SOT223
https://asset.conrad.com/media10/add/160267/c1/-/en/000152901DS01/datasheet-152901-infineon-technologies-bsp308-mosfet-1-n-channel-18-w-sot-223.pdf

[gabortamasko]

1. yes, I use a separate 5V buck for the white board, and even use a 3.3V ldo for optocuplers to monitor external 12v voltage sources (if they are on or off)
2. A simple mini360 style buck converter , preset for 5V
3. I switch it rearly. But when it is stable I can switch it in any combination. In optimal working conditions, none of the relays are "HIGH" (why let them consume power if I know how will it be used in the 99.999% of the time)
4. I use browser only firmware
   Thanks.

Currently I still figuring out maybe my voltage dips for a short time, that makes the board to go below 4V-5V.
Will share my findings....

[nielsonm236]

An initial comment regarding the mosfet. If I'm reading the spec correctly, looking at the typical transfer characteristics on page 6, the drain current will only be 2 to 3 mA with the gate at 2.5 to 3V (the output voltage on the Network Module pin). I don't know the rest of your circuit, for instance if the mosfet drain is directly operating a relay coil. If it is, 2 to 3 mA is very low for a relay coil and may cause the relay to "chatter", generating power supply noise. But again, I don't know what your circuit looks like. If there is some additional coil driver then the mosfet drain current is probably fine.

Next: Is the input to the 5V buck converter the same 12V that runs the relays? If yes, an experiment you could try is to temporarily power the Network Module from a completely separate 5V power source ... perhaps a "wall wart" power supply that provides at least 500mA. That experiment is only to make sure we aren't somehow getting power noise on 5V caused by relay operation creating surge current (and a momentary drop in 12V).

I'm very interested in helping to solve this.

Mike

[gabortamasko]

Im using this relay board: https://imgaz1.staticbg.com/thumb/large/oaupload/banggood/images/94/75/8657adaa-8547-4c9b-88f1-d0ed7a39e8c4.jpg.webp but a 12V variant,
Its inputs needs pulled to gnd.
So there is minimal current usage at 3.3V even for n mosfet.

Regarding a the second suggestion, will try out, thanks.

[nielsonm236]

Agreed - the mosfet drain current is not an issue. So I do think we are back to making sure the Network Module power is very clean. The STM8S processor power reset circuit is very sensitive.

My thoughts while power is investigated: Despite my suspicion that there is a power problem I am still puzzled that you are losing pin type, invert, and timer settings. Pin type and invert are stored in EEPROM on the STM8S. Timer settings are stored in Flash on the STM8S. I don't think these would be affected by a simple STM8S reset, even if that reset occurred intermittently. I am wondering if the buck converter is a bit noisy. Sometimes they produce a very high frequency noise on their power output ... a 1000uF cap will help with surges, but typically won't help with high frequency noise. So if we find that a separate 5V power supply works (without the buck converter). then maybe we can look at how to quiet down the output of the buck converter and get you back to your original design.

Mike

[gabortamasko]

Some hours later.

I disconnected all external diveces to minimise power fluctuations,
Added extra caps for 5V
Measured with scope, the 5v buck has 70mv p2p noise,, since the white board uses 3.3V LDO it has a good noise suppressing for external 5v, so this should not be an issue.

I just realized, the bug that makes the board go crazy
can be reproduced.

I even disconnected the relay board.... yes there is nothing on the output (except the mosfets).

• On a single tab open configuration,
• setup all desired settings
• save
• open in a new tab the io control page
• simply press save without fidling with the states
  and boom, the board may go crazy.
  I have to resetup everything.
  Well I have to add, that sometimes, I have to change some states to make it go crazy and forget settings.

Cheat:
By switching back to the configuration tab in browser, the settings are still there, just have to press save again.
there is a 75% chance that after config save, the board bahaves crazy (needs iocontrol page interaction) .
Sw reboot does not help.

Incase of 25% when the board works great, I can switch around as much I want.

here are the stats:

Link Error Statistics
31 0000000015
32 0000000040
33 0000000000
35 0000000000

Network Statistics
Values shown are since last power on or reset

0000000000 Dropped packets at the IP layer
0000000051 Received packets at the IP layer
0000000042 Sent packets at the IP layer
0000000000 Packets dropped due to wrong IP version or header length
0000000000 Packets dropped due to wrong IP length, high byte
0000000000 Packets dropped due to wrong IP length, low byte
0000000000 Packets dropped since they were IP fragments
0000000000 Packets dropped due to IP checksum errors
0000000000 Packets dropped since they were not ICMP or TCP
0000000000 Dropped ICMP packets
0000000000 Received ICMP packets
0000000000 Sent ICMP packets
0000000000 ICMP packets with a wrong type
0000000000 Dropped TCP segments
0000000054 Received TCP segments
0000000045 Sent TCP segments
0000000000 TCP segments with a bad checksum
0000000000 TCP segments with a bad ACK number
0000000000 Received TCP RST (reset) segments
0000000002 Retransmitted TCP segments
0000000000 Dropped SYNs due to too few connections avaliable
0000000000 SYNs for closed ports, triggering a RST

[gabortamasko]

Addiotional testcase
After configuration setup, and after a power off/on, the issue did not occure after a fresh bootup.
Tried 10+ times.

[nielsonm236]

So if I understand your comments you are seeing problems when you use two different tabs in the same browser to make changes (a Save causes the change process to run even if there is nothing to save). I must admit I never tried that. In my manual I recommend avoiding using multiple browsers on multiple computers to make and Save changes, as I know this can cause confusion and settings corruption. But I never tried two tabs in the same Browser. I will try this here. In the meantime, I recommend using only one tab and to switch between settings pages within that tab.

Let me know if what I'm saying here makes sense with regard to what you saw. In all my testing I always used one tab in one browser when changing settings, and never experienced the problem you are seeing. As an FYI, when a Save is done the code will restart the controller when needed ... so no power off/on should be required.

Mike

[nielsonm236]

An additional comment: I will bet you see the issue using two tabs because they are treated as independent browser sessions, and each session is caching the browser state, which includes the javascript variables. Then a Save in one tab overwrites the Save done by the other tab. So you end up with old settings written to the controller.

If this is the case about all I can do is add a caution to the manual not to use multiple tabs for Saving settings. But first I want to try to reproduce here.

Mike

[gabortamasko]

Yes, you are correct. Same browser 2 tabs.
I wanted to point out, that with 2 tabs it is easy to reproduce => you may find the issue.
Originaly I used only 1 tab.
Later I was using 2 tabs, becasue that way it was easy to reconfigure, since there is no export/import function.

Yet, as I noted it earlier, the problem does not always appear when using multiple tabs.

Please try to debug what casues the data loss.

Thanks