DM365 intermittent hang when configuring AEMIF

Jon,

Did you check the same with different boards? If so, is it the same behavior? What is the change made in your latest PCB revision? Can you post the code where it hangs up?

Hi Jon

We have experienced the exact same problem with a few of our boards and have been scratching our heads for some time, until we found this post on the forum. Our faulty boards have been inspected and I am told they are fine, but given this post, I think we have missed something. I know this is probably a longshot, but I was wondering if you could give me a clue where to look for the soldering fault. Was the fault located with a DM365 pin  or somewhere else?

Thanks,

Ian

An update on this issue for me....

I have done the following which resolves the issue for me. The problem is that I cannot explain why this 'fixes' the problem and would very much appreciate some help from more experienced users for a possible explanation. I am reluctant to deploy this 'solution' (if it is one) until I can understand the problem. Below is an extract of an email I sent to our local Ti representative explaining what I have done and asking for help on an explanation. 

The problem is in u-boot/cpu/arm926ejs/davinci/ether.c of the version of u-boot we use (u-boot 1.3.4 that came with the DM365 EVM). The section of code is pasted below and I have put comments in bold prepended with IAN to indicate where the problems are.

Essentially what happens is when eth_halt() is called from u-boot/net/net.c in NetLoop() it calls davinci_eth_close() as shown below. This issues a teardown for the TX and RX channels and then a soft reset of the EMAC. The problem is that on some of our boards after the teardown of the rx channel (see my comment in the code where is says PROBLEM), the AEMIF seems to stop working. Any attempts to read/write from any AEMIF registers freeze the system. Any read/writes from AEMIF registers *before* the teardowns work fine, so the AEMIF is working up to the point of the teardown. This only seems to happen after a cold boot, if I then assert the reset pin (ie a warm reset) the unit boots fine. I have modified u-boot to enable the davinci watchdog and so on a cold boot, the unit will freeze, a minute later the watchdog times out and resets the unit and it boots up and seems to run fine.

We are using a Micrel KS8001L device from the DM365 reference design (Revision C April 13 2009)
Our ethernet section of the boards is exactly as per the reference design
We are 99% sure that there is no solder fault or any other hardware fault on the board.
We are using the u-boot as supplied in DVSDK3.

I have a few questions that I really need help in answering.

Firstly, the obvious one, why is this happening? I cannot understand how the EMAC driver affects the AEMIF - so some pointers here would be very helpful
In the teardown operation below, as far as I can see, the T/RXTEARDOWN channel should be 0 and not 1 - is this correct?

In fact, if I make the teardown channel 0, this seems to resolve the problem and a cold boot works reliably (ie I do not need to enable the watchdog in uboot). But as I do not understand why, I am concerned.

As far as I can see this should affect all of our boards, but it does not. I cannot understand why, so any ideas would be welcome.

Thanks,

Ian

u-boot/cpu/arm926ejs/davinci/ether.c

/* EMAC Channel Teardown */
static void davinci_eth_ch_teardown(int ch)
{
dv_reg dly = 0xff;
dv_reg cnt;

debug_emac("+ emac_ch_teardown\n");

if (ch == EMAC_CH_TX) {
/* Init TX channel teardown */
/* IAN: As far as I can tell this RXTEARDOWN channel should be 0 as 1 is disabled for the DM365 */
adap_emac->TXTEARDOWN = 1;
for(cnt = 0; cnt != 0xfffffffc; cnt = adap_emac->TX0CP) {
/* Wait here for Tx teardown completion interrupt to occur
* Note: A task delay can be called here to pend rather than
* occupying CPU cycles - anyway it has been found that teardown
* takes very few cpu cycles and does not affect functionality */
dly--;
udelay(1);
if (dly == 0)
{
/*IAN: If the RXTEARDOWN channel is 1, then this timeout happens */
printf("TX Teardown did not complete\n");
break;
}
}
adap_emac->TX0CP = cnt;
adap_emac->TX0HDP = 0;
} else {
/* Init RX channel teardown */
/* IAN: As far as I can tell this RXTEARDOWN channel should be 0 as 1 is disabled for the DM365 */
adap_emac->RXTEARDOWN = 1;
for(cnt = 0; cnt != 0xfffffffc; cnt = adap_emac->RX0CP) {
/* Wait here for Rx teardown completion interrupt to occur
* Note: A task delay can be called here to pend rather than
* occupying CPU cycles - anyway it has been found that teardown
* takes very few cpu cycles and does not affect functionality */
dly--;
udelay(1);
if (dly == 0)
{
/*IAN: If the RXTEARDOWN channel is 1, then this timeout happens */
printf("RX Teardown did not complete\n");
break;
}
}
adap_emac->RX0CP = cnt;
adap_emac->RX0HDP = 0;
}

debug_emac("- emac_ch_teardown\n");
}

/* Eth device close */
static int davinci_eth_close(void)
{
debug_emac("+ emac_close\n");

/* IAN: AEMIF register read works here */

davinci_eth_ch_teardown(EMAC_CH_TX); /* TX Channel teardown */
davinci_eth_ch_teardown(EMAC_CH_RX); /* RX Channel teardown */

/* IAN: AEMIF register read freezes here occasionally - PROBLEM */

/* Reset EMAC module and disable interrupts in wrapper */
adap_emac->SOFTRESET = 1;

#if defined(CFG_DM6467_EVM) || defined(CFG_DM365_EVM)
adap_ewrap->SOFTRST = 1;
#else
adap_ewrap->EWCTL = 0;
#endif
debug_emac("- emac_close\n");
return(1);
}

Hi

Did you solve the halt problem ? I meet the same problem with you. But if you change adap_emac->TXTEARDOWN = 0; -> adap_emac->TXTEARDOWN = 1, the halt problem disappeared, though the correct value of TXTEARDOWN is 0.

We test this problem on twenty boards, only find one board has this problem.

Hi

No, unfortunately, I have not resolved this. I am stumped at the moment and have had zero feedback from the forums to shed some light. I have tried our local Ti representative as well and the feedback from them has not answered my questions. So as it stands, I have no idea why this happens as it does.........sorry I can't be of more help

Ian