From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Massa To: "Jonathan Larmour (E-mail)" Cc: "eCos (E-mail)" Subject: [ECOS] Re: RedBoot Date: Mon, 30 Apr 2001 10:04:00 -0000 Message-id: <281963D01A08D511A5D700A0C9AC979A04EF08@EXCHANGE> X-SW-Source: 2001-04/msg00494.html The .reg file helped out. Now the tests run fine. However, the ping_test still had the same result as running my application, where it would try to initialize the Ethernet port and the board would hang. Then the Config Tool would disconnect from the target. The other things I tried were: - Moving the creation of the interrupt in quicc_eth_init to the end of the routine. This failed with the same outcome as before. - I removed a line (shown below) in the quicc_eth_init because of the comment of shutting down the Ethernet. I thought this would have been the problem since I was debugging using the Ethernet port, and obviously, shutting it down would be very bad. This failed with the same outcome as before, too. // Shut down ethernet, in case it is already running scc->scc_gsmr_l &= ~(QUICC_SCC_GSML_ENR | QUICC_SCC_GSML_ENT); - I disabled interrupts at the beginning of the quicc_eth_init routine using HAL_DISABLE_INTERRUPTS and re-enabled them at the end using HAL_RESTORE_INTERRUPTS. This failed and hung the board the same way as before. - I also tried using a static IP address. I didn't think this would work since the failure occurs way before the IP address is used. This failed as well. It seemed as though the failure was occurring when the code tried to access the volatile struct ethernet_pram *enet_pram variable in quicc_eth_init. It was hard to be absolutely certain because there were some failures that occurred at different points in the routine, but it seemed that the code that used this variable caused the most immediate failures. I don't know if there is some sort of contention problem with accessing the Ethernet registers while RedBoot/GDB is running or what. I did try to run while stepping through the quicc_eth_init routine and also just running without any breakpoints, however, the hung board result was the same in both running modes. Do you have any additional insight for this problem? I really appreciate your help. --Anthony