Ethernet Driver

[Doyle, Bryon Thomas (Bryon)]

Hello, Thanks for clearing up the issue on old vs. new exception handling. I think the problem is with the stack overrunning its boundaries; when we initially loaded RTEMS onto our board we had to make several adjustments to the underlying boot monitor program in order for RTEMS to properly run. I think perhaps RTEMS is configured to use more ram than actually is on the board, or possibly conflicting with the space reserved for the boot monitor program. I was wondering where RTEMS's memory map is defined, more specifically where are the RAM boundaries defined?  

Also, I was wondering exactly what it means when a "host unreachable" error is produced, because I get those errors during the initialization of the Routing Table prior CPU crashing. Both the send and receive tasks start up and block waiting for an event from the ISR routine, then the error message comes up. I'm assuming there may be a problem in my send packet function since RTEMS says it is unable to talk to the network.

In response to your other question I have the UART running on the board for terminal output to my PC as well as a BDI2000 for JTAG debugging.

Thanks Again and any help is greatly appreciated.

Bryon Doyle
Bell Labs Summer Intern
Lucent Technologies


-----Original Message-----
From: Thomas Doerfler (nt) [mailto:Thomas.Doerfler at imd-systems.de]
Sent: Friday, July 22, 2005 1:41 PM
To: Doyle, Bryon Thomas (Bryon)
Cc: rtems-users at rtems.com
Subject: Re: Ethernet Driver


Hi,

if you look at the gen68360 BSP (m68k architecture, always using the old
exception handling), you will see that ethernet is "compatible" with
both exception handling methods. The API of the two exception handling
models differs, but I think you are aware of this.

The crashes of your CPU can have a lot of reasons. Since the LED on your
board is on, you might experience a "checkstop" condition, which means,
you get an exception while the processing of machine check exceptions is
disabled. Typically this is caused by a stack overrun or a severe bug in
the exception handling code.

Where is the interrupt line of the ethernet controller connected to? And
what kind of debugging capabilities do you have on this board
(JTAG/UART/LEDs/???).

wkr,
Thomas.


Doyle, Bryon Thomas (Bryon) schrieb:
> Hello, Over the past week or so my task has been to add Ethernet functionality to the CSB472, a slightly modified version of the gen405 BSP package. I have created an Ethernet driver using other RTEMS Ethernet drivers and a Ethernet driver for the board that was designed for another RTOS. The problem that I am having now I believe is with the exception handling; I know that the gen405 BSP is still using the old exception handling model, and from looking around in the other BSP that also still uses the old exception handling model I see that it does not offer Ethernet support.  My question is can the old exception handling model support the burden of an Ethernet driver? I am inclined to think so, but the absence of any other BSP that uses old exception handling and has an Ethernet driver built in, begs me to ask the question. Also I have traced through the initialization of my driver and RTEMS crashes with a CPU error (SYSERR LED on the board lighting up, which I believe is
 m!
>  apped to several machine check exception's happening back to back) as soon as the Ethernet interrupts are enabled through the universal interrupt controller. Which leads me to think that the problem is somewhere within the RTEMS exception handling code.  If anybody has any insight it would be greatly appreciated, thanks again.
> 
> 
> 
> Bryon Doyle
> Summer Intern, Bell Labs
> Lucent Technologies


-- 
--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at:
     http://www.imd-systems.de/pgpkey_en.html