Hi,
> Now i changed the linker entry point as you said.
I also had to change the cw project wizard's PLL initialization code, which was running my 66 MHz part at 80 MHz! :-) So I decided to eliminate everything that was unnecessary from my initialization sequence created by the cw project wizard, and am left with just the attached files if you want to see them -- the linker entry point is still _asm_startmeup. This reduces code bloat (printf(3) is huge and makes RAM debugging almost impossible for all but the smallest program!) and makes it a lot easier for me to follow what is actually going on!
> What is the use of "mcf5222x_vectors.s" file ...
From what I can tell, the only purpose of this is to set the initial startup vectors and flash configuration information. Once these are used, everything else is copied to and used from RAM. You can see from my code that all vectors except 0 and 1 (initial sp and pc) simply "halt", so they are simply unneeded. I then patch the RAM values in my boot sequence, so I have a consistent model for when running from either FLASH or RAM (which has the quicker debug cycle, though you can typically only debug a subset of your code because of the 16k/32k limitation).
As for your code, just looking at MCF52223_EnableEndpoint(), it seems you might be confusing the two separate "toggles"... One "toggle" is the even/odd selector for the BDT to allow concurrent outstanding commands, and the other is specified by USB for data0/data1 phase sequencing.
In your code, when you reset the BDT data toggles:
void MCF52223_ResetBDT (void)
{
CPU_INT08U idx;
/* RESET All BDT ODD bits to zero */
MCF_USB_CTL |= MCF_USB_CTL_ODD_RST;
MCF_USB_CTL &= ~MCF_USB_CTL_ODD_RST;
for (idx = 0; idx < MCF52223_MAX_EPS; idx++) {
EpInf[idx] = 0;
}
}
You reset EpInf[] to 0. This would lead me to believe EpInf is the even/odd BDT toggle (not the data0/data1 toggle). But then later you use EpInf as the data0/data1 toggle (*not* as the even/odd toggle):
void MCF52223_EnableEndpoint (CPU_INT08U ep_addr, CPU_INT08U odd_bnk)
{
CPU_INT08U data_tgl_bit;
CPU_INT32U bdt_attr;
data_tgl_bit = GET_DATA_TOGGLE(EpInf[EP(ep_addr)]);
bdt_attr = BDT_Read(BDT_BASE_ATTR_CORE(ep_addr, odd_bnk));
if (EP_DIR(ep_addr)) {
bdt_attr &= ~(0xFF);
}
bdt_attr |= (MCF_BDT_CTL_OWN | data_tgl_bit | MCF_BDT_CTL_DTS);
BDT_Write(BDT_BASE_ATTR_CORE(ep_addr, odd_bnk), bdt_attr);
}
To my understanding, these two toggles should be managed completely independently... Setting MCF_USB_CTL_ODD_RST should *not* change the data0/data1 toggle state, and a new setup transaction should not change the BDT even/odd toggle state.
The even/odd toggle is used *only* as a parameter to what you call "bnk" in BDT_BASE_ATTR_CORE() and BDT_BASE_ADDR_CORE(). For a host USB driver, there is only one of these since you only use endpoint 0. It is reset when you set MCF_USB_CTL_ODD_RST.
The data0/data1 toggle, on the other hand, is used as a parameter to what you call "val" in BDT_Write() and BDT_Read(). There is one of these per logical endpoint. It is set to data0 for a setup transaction and data1 for a status transaction. It is reset at various times called out in the spec, most notably on a configuration event on a bulk endpoint.
If you want to check out when I toggle, you can see my code (
http://www.testardi.com/rich/coldfire/) and search for "toggle" to see the USB-specified data0/data1 toggle, and "bdtodd" to see the coldfire USB module hardware BDT odd/even toggle.
-- Rich