Problems with the USB initialization

[wolfen]

Posted on November 28, 2007 at 06:58

Problems with the USB initialization

[wolfen]

Posted on July 30, 2007 at 12:29

Hi everybody !

I work with the STR710 on a development board from Embest.

I need to use the USB interface, and I have begun with the code examples, like one that emulates the mouse behaviour. But, for a reason I don't know, the program is waiting for an interrupt which doesn't come, and nothing is working... I have not changed anything on the original code, so I don't know where is the problem. The software is uploaded on RAM, with CodeWarrior, I have put the jumpers in the right places, I can see the program running with the Debug mode... So I think I have other things to initialize, but I don't know what...

Someone has an idea ? Here is the source code :

Code:

<BR> main() <BR> { <BR> <BR> Set_System(); <BR> Set_USBClock(); <BR> USB_Interrupts_Config(); <BR> USB_Init(); <BR> Keys_Config(); <BR> /* Main loop */ <BR> while(1) <BR> { <BR> Joystick_Send(ReadUSBKeys()); <BR> } <BR> } <BR> <BR>void USB_Init(void) <BR>{ <BR> pInformation = &Device_Info; <BR> pInformation->ControlState = 2; <BR> pProperty = &Device_Property; <BR> pUser_Standard_Requests = &User_Standard_Requests; <BR> /* Initialize devices one by one */ <BR> pProperty->Init(); // Call of Joystick_Init() <BR>} <BR> <BR>void Joystick_init(void) <BR>{ <BR> <BR> pInformation->Current_Configuration = 0; <BR> /* Connect the device */ <BR> PowerOn(); <BR> /* USB interrupts initialization */ <BR> _SetISTR(0); /* clear pending interrupts */ <BR> wInterrupt_Mask = IMR_MSK; <BR> _SetCNTR(wInterrupt_Mask); /* set interrupts mask */ <BR> pInformation->Current_Feature = Joystick_ConfigDescriptor[7]; <BR> /* Wait until device is configured (the bug is here) */ <BR> while (pInformation->Current_Configuration == 0) NOP_Process(); <BR> bDeviceState = CONFIGURED; <BR>} <BR>

[ This message was edited by: Wolfen on 30-07-2007 16:02 ]

[anis2399]

Posted on July 31, 2007 at 05:57

Hi Wolfen,

Could you change your configuration and execute the code from the Flash... Could you also verify if in your board you have 16MHz as main clock input and 48MHz for USB clock (the configuration of the USB developer kit from ST)? If it's not the case you should modify the code according to your board...

Regards

The Lion heart

[wolfen]

Posted on July 31, 2007 at 11:50

Thanks for your answer !

I have uploaded my program on Flash Memory and on RAM (with the right jumpers each time) but nothing has changed. The clocks are both at 48 MHz, but that is not the problem I think, I have also a program for the LCD librairies and it works fine with this frequency...

[ This message was edited by: Wolfen on 31-07-2007 15:25 ]

[wolfen]

Posted on August 03, 2007 at 07:30

Hi again

I have more information about my problem. The program is looping without end on the while instruction, waiting for an interruption which has to change the Current_Configuration variable.

This variable can only be modified in a function called ''Standard_SetConfiguration()''. This function is called in only one place, the function NoData_Setup0(). Again, the only place where we can find the new one is the function Setup0_Process(), and so on with CTR_LP(). This function can be find here :

void USB_Istr(void)

{

wIstr = _GetISTR();

/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

#if (IMR_MSK & ISTR_RESET)

if (wIstr & ISTR_RESET & wInterrupt_Mask) {

_SetISTR((u16)CLR_RESET);

Device_Property.Reset();

#ifdef RESET_CALLBACK

RESET_Callback();

#endif

}

#endif

(...)

/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

#if (IMR_MSK & ISTR_CTR)

if (wIstr & ISTR_CTR & wInterrupt_Mask) {

/* servicing of the endpoint correct transfer interrupt */

/* clear of the CTR flag into the sub */

CTR_LP();

#ifdef CTR_CALLBACK

CTR_Callback();

#endif

}

#endif

} /* USB_Istr */

Finally, the last function is called by USBLP_IRQHandler, which handles USB low priority event interrupt.

When I'm debugging the program step by step, it doesn't stop on any of these lines. That means the ISTR interruptions, which are the only ones able to change the critical variable Current_Configuration, are not configured properly.

In the code from my last messages, there is only one line which has something to do with the ISTR interruptions : ''_SetISTR(0);''. I have thought the ''0'' was not the right argument, so I have tried to add some masks here, and on the IMR_MSK because I need ''#if (IMR_MSK & ISTR_CTR)'' to be compiled to allow the ''CTR_LP();'' to be called...

As you can see, I'm hunting this bug :p If someone is seeing something clear inside this... Some help about the ISTR interruptions would be great ! Do you have some ideas ?

Thanks !

[ This message was edited by: Wolfen on 03-08-2007 11:01 ]

[sjo]

Posted on August 03, 2007 at 14:36

May not help, but i think embest uses gcc as the compiler.

early versions of gcc (less than 4.0) fail to corrcetly build the usb lib:

file: usb_init.c

ZORD wInterrupt_Mask;

needs changing to

volatile WORD wInterrupt_Mask;

and in the header file aswell.

Regards

sjo

[wolfen]

Posted on August 06, 2007 at 06:05

Thanks for your answer ;) But I have no problem with the compilation of the USB library...

[sjo]

Posted on August 06, 2007 at 06:34

If you have problems with the build then we will need to see your build log.

Regards

sjo

[wolfen]

Posted on August 06, 2007 at 07:07

My program is compiled, the problem comes during the execution...

[sjo]

Posted on August 06, 2007 at 07:16

Then my point above may help. the fix above cures an execution problem.

Regards

sjo

[ben2]

Posted on August 06, 2007 at 07:20

Do you have access to a usb bus analyzer ? Is the PC seeing the device inserted ?

Also do you have control of the pull up resistor on the USB line (I cant remember which off hand) On my board I set up all of the end points and configured everything and then enabled the pull up. The PC then configured the address, which is what your while loop is waiting for.

If you are not getting an interrupt it is most likely that the PC is not seeing your device.

Ben