Dialog Delay becomes really large

I’m running NET+OS 7.5.2.2 on a connectme_esp and I’m using version 2.0.0 of DigiESP to write a custom application for it.

All is well, other than it gets in a state (after writing a setting via the web interface) where the dialog delay becomes arbitrarily large!

It almost seems as though the hardware parameters are being overwritten somehow. Is this possible?

Here’s what I see in in the terminal when this happens:
HARDWARE PARAMETERS:
Serial channels will use a baud rate of 1094926659
This board’s serial number is
This board’s Ethernet MAC Address is 00:40:9D:43:35:97
After board is reset, start-up code will wait 1094926659 seconds
Default duplex setting for Ethernet connection: Invalid Duplex Setting

Press any key in 1094926659 seconds to change these settings.

Obviously, I’m going to be waiting a while!!! Interesting that is the same value for the baud rate and the dialog delay. This value is 0x41434143 and I’m wondering if that holds some special significance.

Has anyone else seen this?

Thanks in advance.

> 00:40:9D:43:35:97
this indicates that your NVRAM values where reset to factory defaults due to corrupt NVRAM.
defaults, including this one 1094926659 (0x41434143) is non-standart and might be coming from your appconf.h

NVRAM is protected by CRC, which means that upon system boot Netos calculates the CRC and compares it with one previously stored in FLASH calculated during most recent write.
The NVRAM would reset to defaults as you’ve described in 2 cases:
-user requested Reset of NVRAM in serial dialog or through iDigi (or software purposely or accidently calls “reset NVRAM” customizeUseDefaultParams(nvParamsPtr):wink:
-during boot NVRAM CRC check fails and systems decides it needs to reset NVRAM to default values.

This can be caused by accidental FLASH write to NVRAM sector (due to memory leak in code or file-system growing too much for example). Another reason could be a bad FLASH, where read of some blocks is inconsistent. But the most common reason for this to happen is when power-cycle or external reset was triggered during the legitimate system write to NVRAM. If such even comes when system already wrote the new variable to NVRAM but before new calculated CRC was updated there, the CRC check will fail after reboot and system will reset the NVRAM structure to default as designed.

Does your system has to do frequent updates to NVRAM? Can they be eliminated? Was the size of the NVRAM sector increase? Do you use FLASH filesystem? You can consider implementing backup NVRAM sector that will be copied to the main one instead of reset to defaults.

This seems to come from the use of customizeWriteDevBoardParams in network_config_v.c in the web interface code. I’m not sure why we’d ever want to write to that those settings, or was the factory method for storing the IP settings as opposed to calling customizeIamSetInterfaceConfig?