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

[Jonathan Woithe]

Hi Harald

On Mon, Jun 29, 2015 at 05:48:36PM +0200, Harald Kipp wrote:
> On 18.06.2015 08:42, Jonathan Woithe wrote:
> > Is there any chance that this could be merged into mainline?  As far as I
> > can tell, this is required if the RTL8019AS is to be reliably initialised on
> > hardware which has been set up for EEPROM emulation.  Even when the existing
> > mainline code results in a functioning NIC, the NIC has clearly not been set
> > up as expected (based on NutOS 4.4.1 for example) since the NIC LED0 has
> > changed behaviour.
> 
> IMHO it is a bad idea to contaminate Nut/OS drivers with board-specific
> code. Therefore board-specific initialization code had been added to
> Nut/OS some time ago. For Ethernut 1.3 this code includes NIC EEPROM
> emulation and is located in nut/arch/avr/board/ethernut1.c.
> 
> This code will be automatically included and executed, if your board
> config file (nut/conf/ethernut1h.conf) contains
> 
> NUT_INIT_BOARD = ""
> 
> Unfortunately this item is missing in the configuration files of earlier
> hardware revisions.

Right.  We use the 1.3g revision board file, so the absence of the above
line explains my earlier observation that the EEPROM emulation code in
ethernut1.c is not being executed in our case (Ethernut 1.3g).

So, perhaps the real fix is to add this line to the 1.3g configuration file
(and other 1.x configurations which are missing it).  I will try to test
this and see what happens, although I can't guarantee the timing at this
point.

> See the NIC drivers dm9000.c and lan91.c in nut/dev/. They are
> intentionally not in the arch directory, because they can be used by any
> hardware platform. That's far better than creating a new instance for
> every board.

So, having the rtl8019as driver in arch/avr/dev/ is an anomally then?

> If you need other specific initialization routines for your board, you
> are welcome to include them in the mainline. At least provide
> 
> nut/arch/avr/board/[myboard].c
> nut/conf/[myboard].conf

For the purposes of NutOS our board is a 1.3g ethernut so there is no need
to have a specific configuration for our board.  In fact, the trouble we had
with the network could be reproduced on a real 1.3g ethernut that I had
lying around (refer to previous posts).

In other words, the issue doesn't just apply to our board, but probably to
all ethernut 1.3 boards which are equipped with the EEPROM emulation
circuitry.

> You can even include new routines or replacements of existing functions
> or drivers, if this would make Nut/OS run smoother on your hardware.

That is a good thing, but as mentioned our board is pretty much an ethernut
1.3g - any board definition we might use would be exactly the same as that
of the ethernut 1.3g.  There's a CPLD lying on the address/data bus which
contains application-specific peripherals and we also use the i2c bus for
custom purposes, but all this is invisible to the core NutOS.  This is
further reinforced by the fact that our firmware will run fine on a standard
ethernut 1.3g.  The example code I provided exhibited network trouble on
real ethernut 1.3g hardware, demonstrating that the issue is not related to
our additional hardware.  Consequently, the issue is with the ethernut 1.3g
architecture (and maybe some earlier 1.3 versions).  From what you've said,
it sounds like this might be due to the omission of the NUT_INIT_BOARD
setting in the 1.3g board configuration.

I will try to get things together to test the NUT_INIT_BOARD theory and let
you know how it goes.

Regards
  jonathan