[En-Nut-Discussion] Unnecessary writing accesses to the eeprom while saving of the network config

[Ulrich Prinz]

Hi guys,

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 
switched on.
Any ongoing (network-)settings are stored into EEPROM from that initial 
time onwards.

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 
anywhere else.

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