[ECOS] Problem with TCP/IP stack

Antoine Zen-Ruffinen antoine.zen@gmail.com
Fri Jan 11 16:38:00 GMT 2008


IT WORK NOW!!!!!

2008/1/11, Gary Thomas <gary@mlbassoc.com>:
> Antoine Zen-Ruffinen wrote:
> > Yes i have CYGIMP_HAL_INTERRUPTS_CHAIN = true in configtool. Does I
> > need something else ? My target is i386-PC.
>
> That just says that your HAL knows *how* to managed chained interrupts.
>
> You also need CYGIMP_KERNEL_INTERRUPTS_CHAIN, so the kernel will
> support chained interrupts for ISRs.
>
> > 2008/1/11, Gary Thomas <gary@mlbassoc.com>:
> >> Antoine Zen-Ruffinen wrote:
> >>> Ok, I am trying to do that. But if the ISR of my fist interface return
> >>> 0, the ISR of the second interface is not called. Does it nead to have
> >>> 2 different ISR routine or the same with different parameter is enough
> >>> ?
> >> You can use the same ISR with different parameters.
> >>
> >> Do you have interrupt chaining enabled?
> >> Does your HAL properly support chained interrupts?  (what's your target?)
> >>
> >>> 2008/1/11, Gary Thomas <gary@mlbassoc.com>:
> >>>> Antoine Zen-Ruffinen wrote:
> >>>>> Ok, I found the problem but I dont' know how to solve it: My two NIC
> >>>>> are sharing the same interrupt. So when the second NIC do an
> >>>>> interrupt, it is handel like it is the first NIC that interrupt.
> >>>>>
> >>>>> Does someone know how to solve such an issue ?
> >>>>>
> >>>> The key is to make your interrupt handler (ISR) tell the upper
> >>>> layers which board did it.  This is reflected in the (struct eth_drv_sc *)
> >>>> parameter that you pass upstream.  Somehow, your driver will have
> >>>> to keep track of these (there is one such structure per physical
> >>>> device entity), then determine which board is responsible and
> >>>> use that information to decide which device (i.e. structure) to use.
> >>>>
> >>>> If you're using the same interrupt for both devices, surely you
> >>>> have Interrupt Chaining turned on in eCos?  This allows for multiple
> >>>> ISR/DSR pairs to be registered for the same interrupt.  eCos will
> >>>> call these ISR functions until one of them returns that it had
> >>>> handled the interrupt.  This could be used to easily handle your
> >>>> situation.
> >>>>
> >>>>> 2008/1/11, Antoine Zen-Ruffinen <antoine.zen@gmail.com>:
> >>>>>> Some new discover : If a use only one of the two NIC I have on my
> >>>>>> system, everything work fine. When using two NIC, interrupts all the
> >>>>>> time, even if no network activity, even if doing nothing and ARP
> >>>>>> response are not catch by network stack. So the problem is a conflict
> >>>>>> between both interfaces. Here is my driver declaration (for the i386
> >>>>>> platform), maybe something wrong there :
> >>>>>>
> >>>>>> #include <cyg/hal/hal_cache.h>
> >>>>>> #include <cyg/io/pci.h>
> >>>>>>
> >>>>>>
> >>>>>> static cyg_bool
> >>>>>> find_dp83816_match_func(cyg_uint16 v, cyg_uint16 d, cyg_uint32 c, void *p)
> >>>>>> {
> >>>>>>     return ((v == 0x100B) && (d == 0x0020));
> >>>>>> }
> >>>>>>
> >>>>>> cyg_pci_device_id devid = CYG_PCI_NULL_DEVID;
> >>>>>> static void
> >>>>>> _i386_pc_eth_init(dp83816_priv_data_t *dp)
> >>>>>> {
> >>>>>>
> >>>>>>     cyg_pci_device dev_info;
> >>>>>>
> >>>>>>
> >>>>>>     if (cyg_pci_find_matching( &find_dp83816_match_func, NULL, &devid )) {
> >>>>>>         cyg_pci_get_device_info(devid, &dev_info);
> >>>>>>         cyg_pci_translate_interrupt(&dev_info, &dp->interrupt);
> >>>>>>         dp->base = (cyg_uint8 *)(dev_info.base_map[0] & ~1);
> >>>>>>         diag_printf("DP83816 at %p, interrupt: %x\n", dp->base, dp->interrupt);
> >>>>>>     }
> >>>>>> }
> >>>>>>
> >>>>>> #undef  CYGHWR_NS_DP83816_PLF_INIT
> >>>>>> #define CYGHWR_NS_DP83816_PLF_INIT(dp) _i386_pc_eth_init(dp)
> >>>>>>
> >>>>>> // Align buffers on a cache boundary
> >>>>>> #define RxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM * _DP83816_BUFSIZE)
> >>>>>> #define TxBUFSIZE (CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM * _DP83816_BUFSIZE)
> >>>>>> static unsigned char dp83816_eth0_rxbufs[RxBUFSIZE]
> >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE)));
> >>>>>> static unsigned char dp83816_eth0_txbufs[TxBUFSIZE]
> >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE)));
> >>>>>> static dp83816_bd_t
> >>>>>> dp83816_eth0_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM]
> >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE)));
> >>>>>> static dp83816_bd_t
> >>>>>> dp83816_eth0_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM]
> >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE)));
> >>>>>>
> >>>>>> static unsigned char dp83816_eth1_rxbufs[RxBUFSIZE]
> >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE)));
> >>>>>> static unsigned char dp83816_eth1_txbufs[TxBUFSIZE]
> >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE)));
> >>>>>> static dp83816_bd_t
> >>>>>> dp83816_eth1_rxbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM]
> >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE)));
> >>>>>> static dp83816_bd_t
> >>>>>> dp83816_eth1_txbd[CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM]
> >>>>>> __attribute__((aligned(HAL_DCACHE_LINE_SIZE)));
> >>>>>>
> >>>>>>
> >>>>>> // eth0 delacration
> >>>>>> char _i386_pc_eth0_ESA[6];
> >>>>>> static dp83816_priv_data_t dp83816_eth0_priv_data = {
> >>>>>>     "eth0_esa",
> >>>>>>     _i386_pc_eth0_ESA,
> >>>>>>     CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM,    // Number of Rx buffers
> >>>>>>     dp83816_eth0_rxbufs,                    // Rx buffer space
> >>>>>>     dp83816_eth0_rxbd,                      // Rx buffer headers
> >>>>>>     CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM,    // Number of Tx buffers
> >>>>>>     dp83816_eth0_txbufs,                    // Tx buffer space
> >>>>>>     dp83816_eth0_txbd,                      // Tx buffer headers
> >>>>>> };
> >>>>>>
> >>>>>> ETH_DRV_SC(dp83816_sc0,
> >>>>>>            &dp83816_eth0_priv_data, // Driver specific data
> >>>>>>            "eth0",
> >>>>>>            dp83816_start,
> >>>>>>            dp83816_stop,
> >>>>>>            dp83816_control,
> >>>>>>            dp83816_can_send,
> >>>>>>            dp83816_send,
> >>>>>>            dp83816_recv,
> >>>>>>            dp83816_deliver,     // "pseudoDSR" called from fast net thread
> >>>>>>            dp83816_poll,        // poll function, encapsulates ISR and DSR
> >>>>>>            dp83816_int_vector);
> >>>>>>
> >>>>>> NETDEVTAB_ENTRY(dp83816_netdev0,
> >>>>>>                 "eth0",
> >>>>>>                 dp83816_init,
> >>>>>>                 &dp83816_sc0);
> >>>>>>
> >>>>>> // eth1 delacration
> >>>>>> char _i386_pc_eth1_ESA[6];
> >>>>>> static dp83816_priv_data_t dp83816_eth1_priv_data = {
> >>>>>>     "eth1_esa",
> >>>>>>     _i386_pc_eth1_ESA,
> >>>>>>     CYGNUM_DEVS_ETH_I386_PC_DP83816_RxNUM,    // Number of Rx buffers
> >>>>>>     dp83816_eth1_rxbufs,                    // Rx buffer space
> >>>>>>     dp83816_eth1_rxbd,                      // Rx buffer headers
> >>>>>>     CYGNUM_DEVS_ETH_I386_PC_DP83816_TxNUM,    // Number of Tx buffers
> >>>>>>     dp83816_eth1_txbufs,                    // Tx buffer space
> >>>>>>     dp83816_eth1_txbd,                      // Tx buffer headers
> >>>>>> };
> >>>>>>
> >>>>>> ETH_DRV_SC(dp83816_sc1,
> >>>>>>            &dp83816_eth1_priv_data, // Driver specific data
> >>>>>>            "eth1",
> >>>>>>            dp83816_start,
> >>>>>>            dp83816_stop,
> >>>>>>            dp83816_control,
> >>>>>>            dp83816_can_send,
> >>>>>>            dp83816_send,
> >>>>>>            dp83816_recv,
> >>>>>>            dp83816_deliver,     // "pseudoDSR" called from fast net thread
> >>>>>>            dp83816_poll,        // poll function, encapsulates ISR and DSR
> >>>>>>            dp83816_int_vector);
> >>>>>>
> >>>>>> NETDEVTAB_ENTRY(dp83816_netdev1,
> >>>>>>                 "eth1",
> >>>>>>                 dp83816_init,
> >>>>>>                 &dp83816_sc1);
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>:
> >>>>>>> The previous post "[ECOS] Cannot sendto multicast using FreeBSD stack"
> >>>>>>> put me on the way!!
> >>>>>>>
> >>>>>>> No IP packet are send, but ARP  is done. But it seem that the stack
> >>>>>>> doesn't get the ARP reply witch is on the wire. When calling send(),
> >>>>>>> for the fist calls, send() return > 0, but with errno=2 (No such
> >>>>>>> entry) then send() return -1 wiht erron=364 (Host is down). Can this
> >>>>>>> be because I have 2 NIC that share the same interrupt ?
> >>>>>>>
> >>>>>>> 2008/1/10, Antoine Zen-Ruffinen <antoine.zen@gmail.com>:
> >>>>>>>> Sorry for the preceding message that was not send to the list, little
> >>>>>>>> mistake from me (cliqued "reply" and not "reply to all").
> >>>>>>>>
> >>>>>>>> Yes my application print about DHCP transaction and it is ok. I have
> >>>>>>>> added some prints in every driver function in order to trace what it
> >>>>>>>> is doing. The output is interesting :
> >>>>>>>> 1) The NIC is making interrupts all the time
> >>>>>>>> 2) The network stack never call the send() function.
> >>>>>>>>
> >>>>>>>> Here is the output :
> >>>>>>>> RedBoot> load -m tftp -h 192.168.165.18 debugProg
> >>>>>>>> Entry point: 0x00200000, address range: 0x00200000-0x00238840
> >>>>>>>> RedBoot> go
> >>>>>>>> [cyg_net_init] Init: mbinit(0x00000000)
> >>>>>>>> [cyg_net_init] Init: cyg_net_init_devs(0x00000000)
> >>>>>>>> Init device 'eth0'
> >>>>>>>> DP83816 at 0x0000e100, interrupt: 2a
> >>>>>>>> DP83816 - get ESA from EEPROM
> >>>>>>>> DP83816 - ESA: 00:00:24:c8:1d:6c
> >>>>>>>> Init device 'eth1'
> >>>>>>>> DP83816 at 0x0000e200, interrupt: 2a
> >>>>>>>> DP83816 - get ESA from EEPROM
> >>>>>>>> DP83816 - ESA: 00:00:24:c8:1d:6d
> >>>>>>>> [cyg_net_init] Init: loopattach(0x00000000)
> >>>>>>>> [cyg_net_init] Init: ifinit(0x00000000)
> >>>>>>>> [cyg_net_init] Init: domaininit(0x00000000)
> >>>>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x00238000)
> >>>>>>>> New domain internet at 0x00000000
> >>>>>>>> [cyg_net_init] Init: cyg_net_add_domain(0x002378e0)
> >>>>>>>> New domain route at 0x00000000
> >>>>>>>> [cyg_net_init] Init: call_route_init(0x00000000)
> >>>>>>>> [cyg_net_init] Done
> >>>>>>>> Network testing program V2
> >>>>>>>> Thread started
> >>>>>>>>  Init network : DP83816 - ISR on eth0
> >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode
> >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode
> >>>>>>>> DP83816 - can_send on eth0 : 16
> >>>>>>>> DP83816 - send on eth0
> >>>>>>>> DP83816 - can_send on eth0 : 15
> >>>>>>>> DP83816 - deliver on eth0
> >>>>>>>> DP83816 - pool on eth0
> >>>>>>>> DP83816 - Tx Event on eth0
> >>>>>>>> DP83816 - Rx event on eth0
> >>>>>>>> DP83816 - recv on eth0
> >>>>>>>> DP83816 - recv on eth0
> >>>>>>>> DP83816 - can_send on eth0 : 16
> >>>>>>>> DP83816 - send on eth0
> >>>>>>>> DDP83816 - ISR on eth0
> >>>>>>>> P83816 - can_send on eth0 : 15
> >>>>>>>> DP83816 - deliver on eth0
> >>>>>>>> DP83816 - pool on eth0
> >>>>>>>> DP83816 - Tx Event on eth0
> >>>>>>>> DP83816 - Rx event on eth0
> >>>>>>>> DP83816 - recv on eth0
> >>>>>>>> BOOTP[eth0] op: REQUEST
> >>>>>>>>        htype: Ethernet
> >>>>>>>>         hlen: 6
> >>>>>>>>         hops: 0
> >>>>>>>>          xid: 0xec511d6c
> >>>>>>>>         secs: 0
> >>>>>>>>        flags: 0x80
> >>>>>>>>        hw_addr: 00:00:24:c8:1d:6c
> >>>>>>>>      client IP: 0.0.0.0
> >>>>>>>>          my IP: 192.168.165.254
> >>>>>>>>      server IP: 192.168.165.1
> >>>>>>>>     gateway IP: 0.0.0.0
> >>>>>>>>           file: boots.default
> >>>>>>>>   options:
> >>>>>>>>         DHCP message: 3 REQUEST
> >>>>>>>>         DHCP server id: 192.168.165.1
> >>>>>>>>         DHCP time 51: 43200
> >>>>>>>>         DHCP time 58: 21600
> >>>>>>>>         DHCP time 59: 37800
> >>>>>>>>         subnet mask: 255.255.255.0
> >>>>>>>>             gateway: 192.168.165.1
> >>>>>>>>       domain server: 192.168.165.1
> >>>>>>>>         domain name: v165.itslabb.bth.se.
> >>>>>>>>         DHCP option: 37/55.9: 54 51 58 59 1 3 6 15 28
> >>>>>>>>         DHCP option: 39/57.2: 576
> >>>>>>>>         DHCP requested ip: 192.168.165.254
> >>>>>>>> BOOTP[eth1] op: REPLY
> >>>>>>>>        htype: Ethernet
> >>>>>>>>         hlen: 6
> >>>>>>>>         hops: 0
> >>>>>>>>          xid: 0x0
> >>>>>>>>         secs: 0
> >>>>>>>>        flags: 0x0
> >>>>>>>>        hw_addr: 00:00:24:c8:1d:6d
> >>>>>>>>      client IP: 10.0.0.10
> >>>>>>>>          my IP: 10.0.0.10
> >>>>>>>>      server IP: 0.0.0.0
> >>>>>>>>     gateway IP: 0.0.0.0
> >>>>>>>>   options:
> >>>>>>>>         subnet mask: 255.255.255.0
> >>>>>>>>        IP broadcast: 10.0.0.255
> >>>>>>>>             gateway: 0.0.0.0
> >>>>>>>> DP83816 - ISR on eth0
> >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode
> >>>>>>>> DP83816 - can_send on eth0 : 16
> >>>>>>>> DP83816 - send on eth0
> >>>>>>>> DP83816 - can_send on eth0 : 15
> >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode
> >>>>>>>> DP83816 - can_send on eth0 : 15
> >>>>>>>> DP83816 - send on eth0
> >>>>>>>> DP83816 - can_send on eth0 : 14
> >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode
> >>>>>>>> DP83816 - can_send on eth1 : 16
> >>>>>>>> DP83816 - send on eth1
> >>>>>>>> DP83816 - can_send on eth1 : 15
> >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode
> >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode
> >>>>>>>> DP83816 - can_send on eth1 : 15
> >>>>>>>> DP83816 - send on eth1
> >>>>>>>> DP83816 - can_send on eth1 : 14
> >>>>>>>> [eth_drv_ioctl] Warning: Driver can't set multi-cast mode
> >>>>>>>> Network initalized !
> >>>>>>>> Eth0 is up !
> >>>>>>>> Eth1 is up !
> >>>>>>>> socket() =  3
> >>>>>>>> It seem that everthing is OK. start sending packets.
> >>>>>>>> A - 0> sendto() = 3
> >>>>>>>> B - 0> Waiting for a packet
> >>>>>>>> DP83816 - deliver on eth0
> >>>>>>>> DP83816 - pool on eth0
> >>>>>>>> DP83816 - Tx Event on eth0
> >>>>>>>> DP83816 - ISR on eth0
> >>>>>>>> DP83816 - deliver on eth0
> >>>>>>>> DP83816 - pool on eth0
> >>>>>>>> DP83816 - ISR on eth0
> >>>>>>>> A - 1> sendto() = 3
> >>>>>>>> DP83816 - deliver on eth0
> >>>>>>>> DP83816 - pool on eth0
> >>>>>>>> DP83816 - ISR on eth0
> >>>>>>>> DP83816 - deliver on eth0
> >>>>>>>> DP83816 - pool on eth0
> >>>>>>>> DP83816 - ISR on eth0
> >>>>>>>> DP83816 - deliver on eth0
> >>>>>>>> DP83816 - pool on eth0
> >>>>>>>> DP83816 - ISR on eth0
> >>>>>>>> A - 2> sendto() = 3
> >>>>>>>> DP83816 - deliver on eth0
> >>>>>>>> DP83816 - pool on eth0
> >>>>>>>> DP83816 - ISR on eth0
> >>>>>>>> DP83816 - deliver on eth0
> >>>>>>>> DP83816 - pool on eth0
> >>>>>>>> DP83816 - ISR on eth0
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>:
> >>>>>>>>> Please keep your replies on the eCos list!
> >>>>>>>>>
> >>>>>>>>> **EVERYONE** please get this straight.  Replies made by me on the
> >>>>>>>>> eCos discussion list must be followed up on the eCos discussion list
> >>>>>>>>> unless I invite private replies.  This way everyone benefits, not
> >>>>>>>>> just the interested party.  Private email support consultation and
> >>>>>>>>> support is available, but only with a contract.
> >>>>>>>>>
> >>>>>>>>> Antoine Zen-Ruffinen wrote:
> >>>>>>>>>> The target platform is an embed PC with NS dp83816 NIC. I've port the
> >>>>>>>>>> eCos driver my self for the PC platform.
> >>>>>>>>>>
> >>>>>>>>>> I configure eCos with the configtool, just using the template I made
> >>>>>>>>>> and the "net" package.
> >>>>>>>>>>
> >>>>>>>>>> No, I didn't run a standard eCos network test program. But I build an
> >>>>>>>>>> redboot with this configuration. If I type ping -n 1000 -r 1 -h
> >>>>>>>>>> 192.168.165.18 (is my host PC) everything went fine !
> >>>>>>>>> This is only partly relevant - RedBoot uses a completely different
> >>>>>>>>> network stack than normal eCos applications.  Also, RedBoot does
> >>>>>>>>> not use interrupts, which the eCos stacks rely on.
> >>>>>>>>>
> >>>>>>>>>> I know that nothing was send : 1 becose network activity led doesn't
> >>>>>>>>>> blink, 2 I monitor network with Wireshark (Ethereal). the monitoring
> >>>>>>>>>> trace show the TFTP exchange and the DHCP init but nothing more. It
> >>>>>>>>>> look like this :
> >>>>>>>>>> No.     Time        Source                Destination           Protocol Info
> >>>>>>>>>>   69504 25.515675   192.168.165.18        192.168.165.253       TFTP
> >>>>>>>>>>   Data Packet, Block: 452
> >>>>>>>>>>   69505 25.516279   192.168.165.253       192.168.165.18        TFTP
> >>>>>>>>>>   Acknowledgement, Block: 452
> >>>>>>>>>>   69506 25.516289   192.168.165.18        192.168.165.253       TFTP
> >>>>>>>>>>   Data Packet, Block: 453
> >>>>>>>>>>   69507 25.516662   192.168.165.253       192.168.165.18        TFTP
> >>>>>>>>>>   Error Code, Code: Not defined, Message: redboot
> >>>>>>>>>> tftp_stream_terminate
> >>>>>>>>>>   69508 25.826093   0.0.0.0               255.255.255.255       DHCP
> >>>>>>>>>>   DHCP Discover - Transaction ID 0x6c1dfce9
> >>>>>>>>>>   69511 26.074789   0.0.0.0               255.255.255.255       DHCP
> >>>>>>>>>>   DHCP Discover - Transaction ID 0x6c1dfce9
> >>>>>>>>>>   69512 26.304739   0.0.0.0               255.255.255.255       DHCP
> >>>>>>>>>>   DHCP Discover - Transaction ID 0x6c1dfce9
> >>>>>>>>>>   69514 26.451407   0.0.0.0               255.255.255.255       DHCP
> >>>>>>>>>>   DHCP Request  - Transaction ID 0x6c1dfde9
> >>>>>>>>>>   69516 26.839890   Olicom_c8:1d:6c       Broadcast             ARP
> >>>>>>>>>>   Who has 192.168.165.254?  Gratuitous ARP
> >>>>>>>>>>
> >>>>>>>>> Did your eCos application print anything about the DHCP transaction?
> >>>>>>>>> I'm betting that it did not (which would imply you are having trouble
> >>>>>>>>> with receive interrupts from your driver)
> >>>>>>>>>
> >>>>>>>>>> 2008/1/10, Gary Thomas <gary@mlbassoc.com>:
> >>>>>>>>>>> Antoine Zen-Ruffinen wrote:
> >>>>>>>>>>>> Hi List folks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I've a problem with the TCP/IP stack:
> >>>>>>>>>>>> - I use TFTP to load my program in redboot. That work fine.
> >>>>>>>>>>>> - My application start, call init_all_network_interfaces(), it do the
> >>>>>>>>>>>> DHCP stuff. That work fine.
> >>>>>>>>>>>> - Then I open a socket and try to send / receive data. No packet is even send.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Does someone has already seen such problem ?
> >>>>>>>>>>>> Any idea ?
> >>>>>>>>>>> We'll need more data than this in order to help.
> >>>>>>>>>>>    * What's the target platform?
> >>>>>>>>>>>    * How did you configure eCos for your failing application?
> >>>>>>>>>>>    * Have you run any of the standard eCos network test programs?
> >>>>>>>>>>>    * How do you know nothing was sent?  What sort of debugging
> >>>>>>>>>>>      have you tried so far?
> >> --
> >> ------------------------------------------------------------
> >> Gary Thomas                 |  Consulting for the
> >> MLB Associates              |    Embedded world
> >> ------------------------------------------------------------
> >>
> >
>
>
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



More information about the Ecos-discuss mailing list