Ethercard - stash buffer issue

[Stuart]

Looks like I'm suffering from the same stash buffer issue as others
are seeing. My solar panel upload code seems to work fine for a few
days uploading to 3 websites every 2 minutes. So far the max up time
has been around 4 days, the shortest, about 12 hours.

I'm now uploading the stash free count to Pachube url below..

https://api.pachube.com/v2/feeds/40789/datastreams/StashFree.png?width=730&height=250&colour=%232446f1&duration=1day&title=Ethercard%20Stash%20free&stroke_size=3&show_axis_labels=true&detailed_grid=true&scale=auto&min=0&max=52&timezone=London

Seems that after just 12 hours of running, I've already "lost" 7 stash
buffers. I'm expecting that the software will stop uploading once we
get to a critical level.

[SomeRandomBloke]

There is an issue. Basicly the stash is freed when the tcp call back function is called, but in some circumstances this doesnt happen. Could be down to the main packet look missing a packet, missinterpreting it or something. It doesnt happen every time, dependin gon your polling interval it could be a long time or quite quick. I had a test running with a few seconds between requests and it failed within a few minutes. 

For some reason my latest code has been running since the weekend with no resets.

SRB

[jpdw]

Not sure if it's relevant but over the past week I've found the freecount dropping down significantly less than it was before (whereas it would probably drop to <10 in just a few hours, it's now a day or two -- at critical my watchdog re-inits do my app never actually dies - as hacky workaround !).  This is with a fresh sync from jcw's git repo about 1wk ago. [ my app does a web post every 5 seconds, ie around 17k / day .. so quite a lot]

It may be a co-incidence but I've spent a fair bit of time trying to reduce the RAM utilisation of my code - both by looking thoroughly at my app code (I've changed nothing in the libraries) and the build settings I'm using in Eclipse/AVR Plugin.

I had also wondered if the problem was proportional to the amount of received (/unhandled) network traffic - in previous weeks my home network was more busy and I also had a misconfigured router which meant a lot of unwanted broadcasts including duplicates were hitting the nanode board - maybe causing the issues.