[En-Nut-Discussion] Nutos 5.1 on Ethernut 1.3g with multiple threads: network freezes

[Jonathan Woithe]

Hi Henrik

On Thu, Jun 11, 2015 at 06:33:23PM +1000, hmnews at proconx.com wrote:
> Now you mention EEPROM emulation, that reminded of some issues in the past
> with the RTL8019AS chip we had.

:-)  So general strangeness is not completely unexpected then.

> If the chip is not initialised with correct mode at power-up or reset it can
> cause all sorts of strange behaviour. With one of the designs we had this
> caused some random address decoding issues where the NIC sometimes but not
> always did decode itself into RAM address space causing conflicts with the
> static memory. Obviously this lead to random crashes after the network was
> initialised. Sounds familiar?

Indeed it does.  That sort of behaviour would explain pretty much everything
that I've seen over the last three days of debugging.

> So I think you are on the right track by looking at the init routines and/or
> EEPROM emulation. Good luck, been there before...

Well, as I said it seems that the EEPROM emulation initialisation that was
removed in r4711 has pretty much broken things for us with our application. 
Putting it back in immediately makes everything work correctly.  Having said
that, it seems the actual data emulated isn't all that critical: sending all
ones is sufficient to make things work.  Now, this is more or less what the
ethernut1.c code effectively does, but the nicrtl.c code does a few more
steps either side of the emulation.  My guess is that the combination of
these actions results in a cleaner initialisation.

Another thought I've had is that the power-on initialisation that's now in
ethernut1.c might in fact be excuting too early (coming as it does before
main() is called).  Perhaps the chip just needs a bit more time before it's
hit with this.  I will do some experiments along these lines on Monday.

The only reason given for the removal of this code in r4711 was that the
NutSleep() crashed when the firmware was compiled with "avr-gccdbg".  Does
anyone know what this "avr-gccdbg" means in terms of gcc compile options?  I
could do up a version of gcc to match this and test that too.

In any case, it seems with the code in we may have an issue with avr-gccdbg,
whereas without it there's a problem with normal gcc.  I'm not sure there's
an obvious way to simultaneously address both of these conditions. 
Personally, I think that having something work under a production compiler
is more important than under avr-gccdbg.  As such I am inclined to suggest
that the EEPROM emulation code be added back in, but I will spend a little
more time on Monday to see if the above questions can be answered and
perhaps provide a more definitive idea as to what's going on.

At the end of the day I'm going to need *something* soon since I've already
burnt multiple days on this and need to move on.  If restoring the EEPROM
emulation code proves to be the only way to get reliable operation then
we'll just have to go with that.  Obviously it would be best if upstream
NutOS could incorporate whatever this ends up looking like, but if we end up
having to maintain an out-of-tree patch then that's what we'll do.  Sticking
with a pre-r4711 NutOS isn't really an issue since it can't easily be made
to work with recent (and future) versions of gcc and avr-libc.

Anyway, I'll attempt to resolve the outstanding questions on Monday and we
can take things from there.

Regards
  jonathan