Honored Contributor
Honored ContributorSorry to bring this back up again, but it's a week to ship date and I'm getting desperate.
The HTTP thread stack size was an issue, just not the only issue, apparently. My stack is set to 8192, and the thread monitor (when i can get to it) shows about 2.7K of stack used. I see that there is no way to change the network threads' stack sizes, short of some hacking in ecos-current. I've managed to trace the problem down to this: sometimes the system boots fine, but other times it gets in a mode where it doesn't notice ARP replies that it should. Say you ping the demo board from some other machine. The demo board sends out an ARP request asking for the Ethernet MAC address of the machine doing the ping. The pinging machine sends an ARP reply. However, the demo board doesn't send the ping reply, like it does when it works. The pinging machine times out and sends another ping. The whole process repeats; it's like the demo board did not see the ARP reply from the pinging machine. Cycling power tends to make the problem go away. I'd try a reset, but we don't have a reset button on this machine. I have turned on debug messages with verbosity level 2 in the Common Ethernet part of the I/O subsystem section of the nios2configtool window. I can see the dumps of the packets being sent and received coming across the JTAG UART. I have verified that the stack is getting the ARP packet, that it recognizes it as an ARP packet; I've managed to trace it into the arpintr() function in the common Ethernet driver. The big pain with this problem is that it's difficult to reproduce, and adding the diag_printf calls to debug it is changing its behavior, making the bug less likely to occur. I'm using Quartus 4.2 and Nios II 1.1, along with the eCos that was released for them. It's rather late to run the risk of changing development environments, so I'm wondering if anyone found the fix, or has had this problem.
