The config sector was really designed, way-back-when, as something that would rarely if ever be changed. If NETMF writes to it frequently, then that's an inconsistent design that we need to figure out how to fix in a contribution back to the core...
We can analyze a lot of these things more easily on the new Netduino Go hardware, where we can interactively browse the Flash while running NETMF on the board (using the JTAG connector). I'm really looking forward to getting the first hand-built samples of the new Ethernet module for Netduino Go, and digging into the details of the config sector usage.
Chris
Sounds like a good plan. If the N+ is not erasing and re-writing the configuration sector once all the chained "positions" are used up, then the behavior I saw would make sense. Here are some statics from a system installed at a customer site that might help:
Over a 5 days period of continuous operation, I saw:
14 times the N+ froze and was reset by the watchdog timer.
3 times, following a watchdog reset, the DHCP server (provided by a DSL modem) assigned a different IP address.
1 time, following a watchdog reset, the configuration was updated by my managed code, due to finding bogus data there. Specifically, the IP and gateway addresses had been changed to 0.0.0.0
Note my N+ operates as a client, and the freezes usually occur when creating a socket (on the N+, outgoing sockets cannot be reused unfortunately), but sometimes occur when doing a CONNECT();
I think that means the configuration sector was written to/updated approximately once per day, if we assume a DHCP operation does not cause a configuration write when the IP address is unchanged. And three times per day if it causes a rewrite every time (A DHCP transactions will occur each time there is a reset). And even more if a write occurs behind-the-scenes each time the DHCP client does a "RENEW" transaction.