[En-Nut-Discussion] Unnecessary writing accesses to the eeprom while saving of the network config
uprinz2 at netscape.net
Tue Jan 26 23:00:54 CET 2010
maybe you noticed, that I investigate in that part of the code too. I
just stopped for a while, cause I have some time troubles...
But yes, this code is problematic and the part of the system/network
saving too. While Nut(OS is ist mostly good readable and NutConfig shows
important things, from where they come and where they go, the config
areas are a mess. I have no idea why and how some application saves one
thing in an EEPROM of an RTC while another one saves it in the boot
block of my application... ups.
So my commercial application uses system config, wireless config and
network config in one sector of the CPUs flash. Settings are only saved
if they have changed. Exception is network, but only part of it. The MAC
had become part of the system config as it is flashed at production like
serial-number, product number and product name. This is very practical
as you can do firmware-update without loosing important device specific
information. And you don't have to program a second memory device (i.e.
EEPROM) in mass production process.
On bootup, if an empty or scrambled EEPROM is found, system-name id
copied to network-name, network config is reset to 0 and DHCP is
Any ongoing (network-)settings are stored into EEPROM from that initial
Most CPU/FLASH chips have FLASH sectors of 1k...64k. So system-config
area could be pretty big for such fundamental information. For that it
is quite enough to use only one sector. As other application might
reprogram that sector more often, it is not advised to place code in it.
So the simple change was to move the MAC to the system config. So there
is no extra network config in FLASH while the other one is in EEPROM or
I faced a second problem in the Nutconfig, for not showing the addresses
where these config areas are stored. This should be fixed too.
And then there was an issue with external memories that need a bus that
has to be initialized before. I think it was the SPI subsystem that was
not ready early enough to fetch the config out of a serial FLASH chip.
A simple example for the config mess was a subcontractor who finally
modified the linker script to keep the first sector free for config
savings and place the code at a higher address...
Best regards, Ulrich
More information about the En-Nut-Discussion