Hi guys, I am having some troubles with Martin's USB HID core gnu port. Can anyone help? I got over the 'sh' thing, and have put in relevent SAM7A3 mods for the makefile and openocd, but after burning the code in I get only tab characters coming out on the DBGU, has anyone else experienced this problem? Also the computer doesn't recognise a HID, but thats ok, if i can get the DBGU working I should be able to debug the rest. I have proven out the board I am using; a AT91SAM7A3 board. I have successfully ported two of Martin Thomas's AT91SAM7S examples so far, the openocd gamma project, and the USB-UART which I modded to be a nice USB terminal.. (I have uploaded the UART to mt, but the usb-uart still needs some cleaning up). I am actually attempting to make a USB-joystick.. Anyway, help appreciated, B
Ben Exelty wrote: > Hi guys, > > I am having some troubles with Martin's USB HID core gnu port. Can > anyone help? I got over the 'sh' thing, and have put in relevent SAM7A3 > mods for the makefile and openocd, but after burning the code in I get > only tab characters coming out on the DBGU, has anyone else experienced > this problem? Also the computer doesn't recognise a HID, but thats ok, > if i can get the DBGU working I should be able to debug the rest. > > > I have proven out the board I am using; a AT91SAM7A3 board. I have > successfully ported two of Martin Thomas's AT91SAM7S examples so far, > the openocd gamma project, and the USB-UART which I modded to be a nice > USB terminal.. (I have uploaded the UART to mt, but the usb-uart still > needs some cleaning up). I am actually attempting to make a > USB-joystick.. > > Anyway, help appreciated, > B Hi, I have the same situation as you have with the dbgu things. I use a sam7sek board and cannot get the first TRACE working. I also attemps to simulate a joystick on usb. i put this info on the makefile: TARGET=AT91SAM7S256 BOARD=AT91SAM7SEK CLASS=ENUM MODE=NO REMAP=NO DEBUG=NO LEDS=YES TRACES=YES POWER=AUTO regards Jonathan
Guest wrote: > Ben Exelty wrote: >> Hi guys, >> >> I am having some troubles with Martin's USB HID core gnu port. Can >> anyone help? I got over the 'sh' thing, and have put in relevent SAM7A3 >> mods for the makefile and openocd, but after burning the code in I get >> only tab characters coming out on the DBGU, has anyone else experienced >> this problem? Also the computer doesn't recognise a HID, but thats ok, >> if i can get the DBGU working I should be able to debug the rest. //---------------------------------------------------------------------- -------- // \brief Puts the device back into a normal operation mode //---------------------------------------------------------------------- -------- void DEV_Resume(void) { #if defined(AT91SAM7SEK) || defined(AT91SAM7SEEK) \ || defined(AT91SAM7XEK) || defined(AT91SAM7A3EK) // Enable Main Oscillator // Main Oscillator startup time is board specific: // Main Oscillator Startup Time (18432KHz) corresponds to 1.5ms // (0x08 for AT91C_CKGR_OSCOUNT field) #if defined(AT91SAM7SEK) || defined(AT91SAM7SEEK) || defined(AT91SAM7XEK) AT91C_BASE_PMC->PMC_MOR = (AT91C_CKGR_OSCOUNT & (0x8 << 8)) | AT91C_CKGR_MOSCEN; #elif defined(AT91SAM7A3EK) AT91C_BASE_PMC->PMC_MOR = (AT91C_CKGR_OSCOUNT & (0x40 << 8)) | AT91C_CKGR_MOSCEN; #endif // Wait until the oscillator is stabilized // while (!ISSET(AT91C_BASE_PMC->PMC_SR, AT91C_PMC_MOSCS)); // Set PLL to 96MHz (96,109MHz) and UDP Clock to 48MHz // PLL Startup time depends on PLL RC filter // UDP Clock (48,058MHz) is compliant with the Universal Serial Bus // Specification (+/- 0.25% for full speed) AT91C_BASE_PMC->PMC_PLLR = AT91C_CKGR_USBDIV_1 | AT91C_CKGR_OUT_0 | (AT91C_CKGR_PLLCOUNT & (0x28 << 8)) | (AT91C_CKGR_MUL & (0x48 << 16)) | (AT91C_CKGR_DIV & 0xE); /* AT91C_BASE_PMC->PMC_PLLR = ((AT91C_CKGR_DIV & 14 ) | (AT91C_CKGR_PLLCOUNT & (28<<8)) | (AT91C_CKGR_MUL & (72<<16)));*/ // Wait until the PLL is stabilized while(!ISSET(AT91C_BASE_PMC->PMC_SR, AT91C_PMC_LOCK)); //while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_LOCK)); //while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY)); // Selection of Master Clock MCK (equal to Processor Clock PCK) equal to // PLL/2 = 48MHz // The PMC_MCKR register must not be programmed in a single write operation // (see. Product Errata Sheet) AT91C_BASE_PMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2; while (!ISSET(AT91C_BASE_PMC->PMC_SR, AT91C_PMC_MCKRDY)); //SET(AT91C_BASE_PMC->PMC_MCKR, AT91C_PMC_CSS_PLL_CLK); AT91C_BASE_PMC->PMC_MCKR |= AT91C_PMC_CSS_PLL_CLK ; //while (!ISSET(AT91C_BASE_PMC->PMC_SR, AT91C_PMC_MCKRDY)); while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY)); //* Set Flash Waite sate #elif defined(AT91SAM9261EK) AT91C_BASE_PMC->PMC_IDR = 0xFFFFFFFF; // Setup the PLL A AT91C_BASE_CKGR->CKGR_PLLAR = 0x2060BF09; // crystal= 18.432MHz while (!(*AT91C_PMC_SR & AT91C_PMC_LOCKA)); // Switch Master Clock from PLLB to PLLA/2 AT91C_BASE_PMC->PMC_MCKR = AT91C_PMC_CSS_PLLA_CLK | AT91C_PMC_PRES_CLK | AT91C_PMC_MDIV_2; while (!(*AT91C_PMC_SR & AT91C_PMC_MCKRDY)); #elif defined(AT91RM9200) // Checking the Main Oscillator Frequency (Optional) volatile char tmp = 0; AT91F_PIOD_CfgPMC(); // VBUS // Checking the Main Oscillator Frequency (Optional) // Determine the main clock frequency while(!(AT91C_BASE_CKGR->CKGR_MCFR & AT91C_CKGR_MAINRDY) && (tmp++ < 100)); #endif } but you have to put 1 more instruction before #if defined(AT91SAM7SEK) || defined(AT91SAM7SEEK) || defined(AT91SAM7XEK) AT91C_BASE_MC->MC_FMR = AT91C_MC_FWS_1FWS ; <----- this line AT91C_BASE_PMC->PMC_MOR = (AT91C_CKGR_OSCOUNT & (0x8 << 8)) | AT91C_CKGR_MOSCEN; now the dbgu is working at least on the SAM7S-EK board i will continue to test it today. Jonathan
Dude, you tha man! thanks heaps for the tip! I had a bit more play last night and I figured it must be in the setup because i while(1);'d the program after the first trace_init, and I still couldn't get anything more than tabs coming out. I probably should have said in my first post I am actually using a custom board, which I have defined as AT91SAM7A3_CUSTOM, which, unfortunately means the whole clock init there has been skipped! so this must be the problem, d'oh. The way the DEV_init is put in the startup.S made it tricky too. Well I'll add my custom board to the init and see what happens, will report back in a sec. Jonathan Dumarjo wrote: > Guest wrote: > > but you have to put 1 more instruction before > > #if defined(AT91SAM7SEK) || defined(AT91SAM7SEEK) || > defined(AT91SAM7XEK) > > AT91C_BASE_MC->MC_FMR = AT91C_MC_FWS_1FWS ; <----- this line > > AT91C_BASE_PMC->PMC_MOR = (AT91C_CKGR_OSCOUNT & (0x8 << 8)) > | AT91C_CKGR_MOSCEN; > > > now the dbgu is working at least on the SAM7S-EK board > > i will continue to test it today. > > Jonathan
Ben Exelty wrote: > Well I'll add my custom board to the init and see what happens, will > report back in a sec. It works now!!! Thanks again. Hmm, now for the joystick part...
Ben Exelty wrote: > Ben Exelty wrote: >> Well I'll add my custom board to the init and see what happens, will >> report back in a sec. > > It works now!!! Thanks again. > > Hmm, now for the joystick part... BTW i did have to add that line to get it to work Jon, and the computer recognises a HID when i replug the USB.yay! btw, my mt_defs is now, only: #-- TARGET=AT91SAM7A3 BOARD=AT91SAM7A3_CUSTOM CLASS=HID MODE=KEYBOARD DEBUG=YES POWER=BUS #-- Regards.B
Ben Exelty wrote: > Ben Exelty wrote: >> Ben Exelty wrote: >>> Well I'll add my custom board to the init and see what happens, will >>> report back in a sec. >> >> It works now!!! Thanks again. >> >> Hmm, now for the joystick part... > > > BTW i did have to add that line to get it to work Jon, and the computer > recognises a HID when i replug the USB.yay! > > btw, my mt_defs is now, only: > #-- > TARGET=AT91SAM7A3 > BOARD=AT91SAM7A3_CUSTOM > CLASS=HID > MODE=KEYBOARD > DEBUG=YES > POWER=BUS > #-- > Regards.B it's a good new than ! is it possible for you marten to update your sample file with this little modification ? Jonathan
Jonathan, I am finding that it doesn't report a keyboard on the usb popup on the PC, instead it just reports a USB HID & HID Keyboard in Device Manager (XP system), did you find this as well? should it actually be reporting 'atmel at91 HID keyboard' as in the pProduct descriptor? (From the debug data I can see it sends the pProduct (which is in pStrings[2]), ie, "Hlr Ept0 Stp NewReq Std gDesc Str2 Write0(48) ") Heres the whole log from enumeration: Main HID keyboard Init() Attach(1) Connecting ... OK Hlr Susp Hlr Res Hlr Susp Hlr Res Hlr EoBRes CfgEpt0 Hlr Res Hlr EoBRes CfgEpt0 Hlr Ept0 Stp NewReq Std gDesc Dev Write0(18) Hlr Ept0 Wr 8 Hlr EoBRes CfgEpt0 Hlr Ept0 Stp NewReq Std sAddr Write0(0) Hlr Ept0 Wr 0 EoT SetAddr(1) Hlr Ept0 Stp NewReq Std gDesc Dev Write0(18) Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 2 EoT Hlr Ept0 Rd Ack Hlr Ept0 Stp NewReq Std gDesc Cfg Write0(9) Hlr Ept0 Wr 8 Hlr Ept0 Wr 1 EoT Hlr Ept0 Rd Ack Hlr Ept0 Stp NewReq Std gDesc Str0 Write0(4) Hlr Ept0 Wr 4 EoT Hlr Ept0 Stp NewReq Std gDesc Str3 Write0(26) Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 2 EoT Hlr Ept0 Rd Ack Hlr Ept0 Stp NewReq Std gDesc Cfg Write0(41) Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 1 EoT Hlr Ept0 Rd Ack Hlr Ept0 Stp NewReq Std gDesc W: STD_RequestHandler: Unknown GetDescriptor = 0x06 Stall0 Hlr Ept0 Sta Hlr Ept0 Stp NewReq Std gDesc Str0 Write0(4) Hlr Ept0 Wr 4 EoT Hlr Ept0 Stp NewReq Std gDesc Str2 Write0(48) Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 0 EoT Hlr Ept0 Rd Ack Hlr Ept0 Stp NewReq Std gDesc Str0 Write0(4) Hlr Ept0 Wr 4 EoT Hlr Ept0 Stp NewReq Std gDesc Str2 Write0(48) Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 0 EoT Hlr Ept0 Rd Ack Hlr Ept0 Stp NewReq Std gDesc Dev Write0(18) Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 2 EoT Hlr Ept0 Rd Ack Hlr Ept0 Stp NewReq Std gDesc Cfg Write0(9) Hlr Ept0 Wr 8 Hlr Ept0 Wr 1 EoT Hlr Ept0 Rd Ack Hlr Ept0 Stp NewReq Std gDesc Cfg Write0(41) Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 1 EoT Hlr Ept0 Rd Ack Hlr Ept0 Stp NewReq Std sCfg Write0(0) Hlr Ept0 Wr 0 EoT SetCfg() CfgEpt1 CfgEpt2 Read2(1) Hlr Ept0 Stp NewReq sIdle(0) Write0(0) Hlr Ept0 Wr 0 EoT Hlr Ept0 Stp NewReq Report Write0(57) Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 8 Hlr Ept0 Wr 1 EoT Hlr Ept0 Rd Ack Hlr Ept0 Stp NewReq sReport Read0(1) Hlr Ept0 Rd 1 EoT Write0(0) Hlr Ept0 Wr 0 EoT
Ben Exelty wrote: > Jonathan, > I am finding that it doesn't report a keyboard on the usb popup on the > PC, instead it just reports a USB HID & HID Keyboard in Device Manager > (XP system), did you find this as well? should it actually be reporting > 'atmel at91 HID keyboard' as in the pProduct descriptor? > I think i have sseen something in a forum that we have to change something (productid or vendor id) to make it work correctly. but i haven't test it really much since i'm writing the joystick device. regards Jonathan
Jonathan Dumarjo wrote: > Ben Exelty wrote: >> Jonathan, >> I am finding that it doesn't report a keyboard on the usb popup on the >> PC, instead it just reports a USB HID & HID Keyboard in Device Manager >> (XP system), did you find this as well? should it actually be reporting >> 'atmel at91 HID keyboard' as in the pProduct descriptor? >> > > I think i have sseen something in a forum that we have to change > something (productid or vendor id) to make it work correctly. > > but i haven't test it really much since i'm writing the joystick device. > > regards > > Jonathan can you point me where maybe the forum was? I tried some different things including changing the device descriptors, but didn't change the name. I think actually that if the device uses the HID standard then it reports itself as a HID device and therefore the computer doesnt need a idproduct becuase its already decided on a driver. You can probably still get access to the idproduct from within applications, the application would just have to ask for it, the device manager just doesnt show it. does that sound right? Anyway, I might do the same and just go on with the joystick :P
> can you point me where maybe the forum was? I tried some different > things including changing the device descriptors, but didn't change the > name. I cannot remember where i see it, sorry. > > I think actually that if the device uses the HID standard then it > reports itself as a HID device and therefore the computer doesnt need a > idproduct becuase its already decided on a driver. You can probably > still get access to the idproduct from within applications, the > application would just have to ask for it, the device manager just > doesnt show it. does that sound right? i'm a very newbie with all the usb thing, so i cannot help you much with this. > > Anyway, I might do the same and just go on with the joystick :P good :) Jonathan
BTW, while I remember, I found a bug in this makefile; in the part: >#-------------------------------- ># Check power >#-------------------------------- >ifndef POWER >POWER = AUTO >else >ifneq ($POWER,BUS) >POWER = AUTO >endif >endif the: ifneq ($POWER,BUS) line should be: ifneq ($(POWER),BUS) otherwise the bus powered doesn't work as assumed! Regards, Exelty
I have update the gcc-port of the USB core and HID code from Atmel. This version includes an updated version of make.exe (3.81) so the makefiles of the previous port could be used without massive changes. I have also included the modifications proposed by Jonathan Dumarjo (DEV_resume) and ECC Exelty ($(POWER)). http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index_at91.html#at91_usb1 Quick start: type mtmake all form the command line instead of make all. It seems that the make.exe V3.80 not only ignores the shell-variable and always uses sh.exe when is is found in the path but also does not pass command-line parameters to a "recursivly called" make. So sorry, the makefiles in this release of the gcc-port are still "Win32-only" since it uses the Windows "shell" (cmd). It will be some work to create makefiles compatible with the old make 3.80 as in WinARM 6/06 and an unix-type shell while keeping the "subproject"-structure as in the original Atmel code. Martin Thomas
Martin Thomas wrote: > I have update the gcc-port of the USB core and HID code from Atmel. This > version includes an updated version of make.exe (3.81) so the makefiles > of the previous port could be used without massive changes. I have also > included the modifications proposed by Jonathan Dumarjo (DEV_resume) and > ECC Exelty ($(POWER)). > > http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index_at91.html#at91_usb1 > > Quick start: type mtmake all form the command line instead of make all. > > It seems that the make.exe V3.80 not only ignores the shell-variable and > always uses sh.exe when is is found in the path but also does not pass > command-line parameters to a "recursivly called" make. So sorry, the > makefiles in this release of the gcc-port are still "Win32-only" since > it uses the Windows "shell" (cmd). It will be some work to create > makefiles compatible with the old make 3.80 as in WinARM 6/06 and an > unix-type shell while keeping the "subproject"-structure as in the > original Atmel code. > > Martin Thomas thanks Martin for your good work. Jonathan
Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.