CDC on Avr32uc3
Locked
12
12
|
Hello all,
I have finally managed to get back to a problem I asked here about a few months ago. I am having difficulty getting an elua build working with a USB CDC console on a custom AVR32UC3 based board. I have everything building fine and it seems to run, I just can't get a console up over the USB CDC. I don't have any alternative serial connection. I have also made a simple C program based on atmel's CDC example and this works fine, so I know I am setting up my board (which has a slightly weird clock configuration) correctly. It looks to me like the build script is not defining BUILD_USB_CDC. I have tested this by trying to flash an led (in my main.c main function just before the shell_init()) if BUILD_USB_CDC is not defined and it flashes after I reboot the micro. Looking in my .build directory I do see a src__platform__avr32__usb-cdc.d and object file. I do have sercon = { uart = "cdc", speed = 115200 } in my boards lua config and have configured virtual timers. My setup is otherwise very similar to the mizar32b. I anyone has any ideas, or could let me know how I can check what the new build script is doing with regard to setting all the #defines I would really appreciate it. Thanks! -- Richard Graham _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
With both Linux and Windows on the PC running the termianl emulator,
on the AVR32UC3 there are strange little dances you must perform to have the USB CDC See http://en.wikibooks.org/wiki/Mizar32/USB M On 07/05/2014, Richard Graham <[hidden email]> wrote: > Hello all, > > I have finally managed to get back to a problem I asked here about a few > months ago. I am having difficulty getting an elua build working with a > USB CDC console on a custom AVR32UC3 based board. > > I have everything building fine and it seems to run, I just can't get a > console up over the USB CDC. I don't have any alternative serial > connection. > > I have also made a simple C program based on atmel's CDC example and > this works fine, so I know I am setting up my board (which has a > slightly weird clock configuration) correctly. > > It looks to me like the build script is not defining BUILD_USB_CDC. I > have tested this by trying to flash an led (in my main.c main function > just before the shell_init()) if BUILD_USB_CDC is not defined and it > flashes after I reboot the micro. Looking in my .build directory I do > see a src__platform__avr32__usb-cdc.d and object file. > > I do have sercon = { uart = "cdc", speed = 115200 } in my boards lua > config and have configured virtual timers. My setup is otherwise very > similar to the mizar32b. > > I anyone has any ideas, or could let me know how I can check what the > new build script is doing with regard to setting all the #defines I > would really appreciate it. > > Thanks! > > -- > Richard Graham > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > -- Currently looking for work, see http://martinwguy.co.uk _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Richard Graham
To see what the script is doing with your defines, look in the boards/headers directory in eLua. Look in the board_PLATFORMNAME.h file for your platform. (e.g. for the arduinodue platform you would look in board_arduinodue.h ) Where in the USB process are things not working? Do you not get a USB device at all? Do you get a USB device which is not recognized as USB CDC? (e.g. wrong UID/PID) Do you get a recognized USB CDC device, but no communications over it? > ----- Original Message ----- > From: Richard Graham > Sent: 05/06/14 08:19 PM > To: eLua Users and Development List (www.eluaproject.net) > Subject: [eLua-dev] CDC on Avr32uc3 > > Hello all, > > I have finally managed to get back to a problem I asked here about a few > months ago. I am having difficulty getting an elua build working with a > USB CDC console on a custom AVR32UC3 based board. > > I have everything building fine and it seems to run, I just can't get a > console up over the USB CDC. I don't have any alternative serial connection. > > I have also made a simple C program based on atmel's CDC example and > this works fine, so I know I am setting up my board (which has a > slightly weird clock configuration) correctly. > > It looks to me like the build script is not defining BUILD_USB_CDC. I > have tested this by trying to flash an led (in my main.c main function > just before the shell_init()) if BUILD_USB_CDC is not defined and it > flashes after I reboot the micro. Looking in my .build directory I do > see a src__platform__avr32__usb-cdc.d and object file. > > I do have sercon = { uart = "cdc", speed = 115200 } in my boards lua > config and have configured virtual timers. My setup is otherwise very > similar to the mizar32b. > > I anyone has any ideas, or could let me know how I can check what the > new build script is doing with regard to setting all the #defines I > would really appreciate it. > > Thanks! > > -- > Richard Graham > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hello all,
Thanks for your comments. It seems I don't get a USB device to enumerate at all. No message in dmesg or device in lsusb. I have also tried spying on the usb bus with usbmon and wireshark and I don't see anything transmitted. Again, with my simple test C program /dev/ttyACM0 enumerates and works fine. I am programming over JTAG. I don't seem to have BUILD_USB_CDC in my boards platform header file which seems weird but I also notice that it is not in the file for a Mizar32 build so maybe that is by design. I do have a "Configuration for element 'sercon'" section which is exactly the same as for the Mizar32. The only weird thing with my setup is that I am getting the USB clock from the secondary XTAL controller. I have had the build system substitute a custom pm_configure_clocks.c which I know works with my test program. It compiles fine with elua and sets up the clocks correctly. I know elua is booting fine at least up to where it starts the shell. Perhaps there is somewhere after that which I can check if it has reached? Reading through the code I start to loose track of what is going on after this point. Again, any suggestions greatly appreciated. I really want to get elua working on this device. Thanks, -- Richard Graham On 05/07/2014 11:02 AM, FP AB wrote: > > To see what the script is doing with your defines, look in the boards/headers directory in eLua. > Look in the board_PLATFORMNAME.h file for your platform. > (e.g. for the arduinodue platform you would look in board_arduinodue.h ) > > Where in the USB process are things not working? > Do you not get a USB device at all? > Do you get a USB device which is not recognized as USB CDC? (e.g. wrong UID/PID) > Do you get a recognized USB CDC device, but no communications over it? > > >> ----- Original Message ----- >> From: Richard Graham >> Sent: 05/06/14 08:19 PM >> To: eLua Users and Development List (www.eluaproject.net) >> Subject: [eLua-dev] CDC on Avr32uc3 >> >> Hello all, >> >> I have finally managed to get back to a problem I asked here about a few >> months ago. I am having difficulty getting an elua build working with a >> USB CDC console on a custom AVR32UC3 based board. >> >> I have everything building fine and it seems to run, I just can't get a >> console up over the USB CDC. I don't have any alternative serial connection. >> >> I have also made a simple C program based on atmel's CDC example and >> this works fine, so I know I am setting up my board (which has a >> slightly weird clock configuration) correctly. >> >> It looks to me like the build script is not defining BUILD_USB_CDC. I >> have tested this by trying to flash an led (in my main.c main function >> just before the shell_init()) if BUILD_USB_CDC is not defined and it >> flashes after I reboot the micro. Looking in my .build directory I do >> see a src__platform__avr32__usb-cdc.d and object file. >> >> I do have sercon = { uart = "cdc", speed = 115200 } in my boards lua >> config and have configured virtual timers. My setup is otherwise very >> similar to the mizar32b. >> >> I anyone has any ideas, or could let me know how I can check what the >> new build script is doing with regard to setting all the #defines I >> would really appreciate it. >> >> Thanks! >> >> -- >> Richard Graham >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
Just a quick update to my earlier email about about my USB problem. It looks like elua gets all the way through the boot process and freezes on the first printf statement. I am still not really sure why in the Mizar32 build process it does not included BUILD_USB_CDC in any headers that I can see. I have tried manually adding this to my platforms header file. This time it doesn't crash at the first printf and linux does do something and identify a new USB device. But I get device descriptor read/64 errors and the USB device doesn't enumerate. -- Richard On 05/07/2014 02:20 PM, Richard Graham wrote: > Hello all, > > Thanks for your comments. > > It seems I don't get a USB device to enumerate at all. No message in > dmesg or device in lsusb. I have also tried spying on the usb bus with > usbmon and wireshark and I don't see anything transmitted. Again, with > my simple test C program /dev/ttyACM0 enumerates and works fine. I am > programming over JTAG. > > I don't seem to have BUILD_USB_CDC in my boards platform header file > which seems weird but I also notice that it is not in the file for a > Mizar32 build so maybe that is by design. I do have a "Configuration for > element 'sercon'" section which is exactly the same as for the Mizar32. > > The only weird thing with my setup is that I am getting the USB clock > from the secondary XTAL controller. I have had the build system > substitute a custom pm_configure_clocks.c which I know works with my > test program. It compiles fine with elua and sets up the clocks correctly. > > I know elua is booting fine at least up to where it starts the shell. > Perhaps there is somewhere after that which I can check if it has > reached? Reading through the code I start to loose track of what is > going on after this point. > > Again, any suggestions greatly appreciated. I really want to get elua > working on this device. > > Thanks, > -- > Richard Graham > > > > On 05/07/2014 11:02 AM, FP AB wrote: >> >> To see what the script is doing with your defines, look in the boards/headers directory in eLua. >> Look in the board_PLATFORMNAME.h file for your platform. >> (e.g. for the arduinodue platform you would look in board_arduinodue.h ) >> >> Where in the USB process are things not working? >> Do you not get a USB device at all? >> Do you get a USB device which is not recognized as USB CDC? (e.g. wrong UID/PID) >> Do you get a recognized USB CDC device, but no communications over it? >> >> >>> ----- Original Message ----- >>> From: Richard Graham >>> Sent: 05/06/14 08:19 PM >>> To: eLua Users and Development List (www.eluaproject.net) >>> Subject: [eLua-dev] CDC on Avr32uc3 >>> >>> Hello all, >>> >>> I have finally managed to get back to a problem I asked here about a few >>> months ago. I am having difficulty getting an elua build working with a >>> USB CDC console on a custom AVR32UC3 based board. >>> >>> I have everything building fine and it seems to run, I just can't get a >>> console up over the USB CDC. I don't have any alternative serial connection. >>> >>> I have also made a simple C program based on atmel's CDC example and >>> this works fine, so I know I am setting up my board (which has a >>> slightly weird clock configuration) correctly. >>> >>> It looks to me like the build script is not defining BUILD_USB_CDC. I >>> have tested this by trying to flash an led (in my main.c main function >>> just before the shell_init()) if BUILD_USB_CDC is not defined and it >>> flashes after I reboot the micro. Looking in my .build directory I do >>> see a src__platform__avr32__usb-cdc.d and object file. >>> >>> I do have sercon = { uart = "cdc", speed = 115200 } in my boards lua >>> config and have configured virtual timers. My setup is otherwise very >>> similar to the mizar32b. >>> >>> I anyone has any ideas, or could let me know how I can check what the >>> new build script is doing with regard to setting all the #defines I >>> would really appreciate it. >>> >>> Thanks! >>> >>> -- >>> Richard Graham >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On 08/05/2014, Richard Graham <[hidden email]> wrote:
> It looks like elua gets all the way through the boot process and freezes > on the first printf statement. > > I am still not really sure why in the Mizar32 build process it does not > included BUILD_USB_CDC in any headers that I can see. I have tried > manually adding this to my platforms header file. This time it doesn't > crash at the first printf and linux does do something and identify a new > USB device. But I get device descriptor read/64 errors and the USB > device doesn't enumerate. Hi I've spent a day checking this and you're right. The Mizar32 build is now broken in the "new build system", which has components = { sercon = { uart = "cdc", speed = 115200 }, in boards/known/mizar32[ab].lua but "lua build_elua.lua mizar32b" doesn't define BUILD_USB_CDC in the generated file boards/headers/board_mizar32b.h For what it's worth, you can see whether USB CDC support is included in the binary using: nm elua_lua_mizar32b.elf | grep usb_init I'm not sure how to fix this: if it's obvious to someone who knows the new build system, please go ahead and fix mizar32a and b. If not, I'll have another look at it and see if I can figure it out Cheers M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Richard Graham
Did you include cdc = true, Or cdc = { buf_size = 128 }, -- if you want to set the buffer size. in the components section of the board file? You need that to turn on USB CDC support. See, for example stm32f4discovery.lua I just took a quick look at the mizar32a board file, and noticed that this was not included. I notice it seems to be missing from the soldercore.lua board file as well. I added the fixes to the Miscupdates branch on > ----- Original Message ----- > From: Martin Guy > Sent: 05/10/14 07:41 AM > To: eLua Users and Development List (www.eluaproject.net) > Subject: Re: [eLua-dev] CDC on Avr32uc3 > > On 08/05/2014, Richard Graham <[hidden email]> wrote: > > It looks like elua gets all the way through the boot process and freezes > > on the first printf statement. > > > > I am still not really sure why in the Mizar32 build process it does not > > included BUILD_USB_CDC in any headers that I can see. I have tried > > manually adding this to my platforms header file. This time it doesn't > > crash at the first printf and linux does do something and identify a new > > USB device. But I get device descriptor read/64 errors and the USB > > device doesn't enumerate. > > Hi > I've spent a day checking this and you're right. The Mizar32 build > is now broken in the "new build system", which has > components = { > sercon = { uart = "cdc", speed = 115200 }, > in boards/known/mizar32[ab].lua but "lua build_elua.lua mizar32b" > doesn't define BUILD_USB_CDC in the generated file > boards/headers/board_mizar32b.h > > For what it's worth, you can see whether USB CDC support is > included in the binary using: > nm elua_lua_mizar32b.elf | grep usb_init > > I'm not sure how to fix this: if it's obvious to someone who knows the > new build system, please go ahead and fix mizar32a and b. If not, I'll > have another look at it and see if I can figure it out > > Cheers > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Richard Graham
Sorry, my mail program glitched and sent this before it was done. The branch is in https://github.com/ecdr/elua Had already submitted a pull request on that branch, so added this to it. I don't have the right compiler to build the mizar32, but adding cdc = true included BUILD_USB_CDC in the header file. > ----- Original Message ----- > From: FP AB > Sent: 05/10/14 12:32 PM > To: eLua Users and Development List (www.eluaproject.net) > Subject: Re: [eLua-dev] CDC on Avr32uc3 > > Did you include > cdc = true, > Or > cdc = { buf_size = 128 }, -- if you want to set the buffer size. > > in the components section of the board file? > > You need that to turn on USB CDC support. > See, for example stm32f4discovery.lua > > I just took a quick look at the mizar32a board file, and noticed that this was not included. > I notice it seems to be missing from the soldercore.lua board file as well. > I added the fixes to the Miscupdates branch on > > > > > > > ----- Original Message ----- > > From: Martin Guy > > Sent: 05/10/14 07:41 AM > > To: eLua Users and Development List (www.eluaproject.net) > > Subject: Re: [eLua-dev] CDC on Avr32uc3 > > > > On 08/05/2014, Richard Graham <[hidden email]> wrote: > > > It looks like elua gets all the way through the boot process and freezes > > > on the first printf statement. > > > > > > I am still not really sure why in the Mizar32 build process it does not > > > included BUILD_USB_CDC in any headers that I can see. I have tried > > > manually adding this to my platforms header file. This time it doesn't > > > crash at the first printf and linux does do something and identify a new > > > USB device. But I get device descriptor read/64 errors and the USB > > > device doesn't enumerate. > > > > Hi > > I've spent a day checking this and you're right. The Mizar32 build > > is now broken in the "new build system", which has > > components = { > > sercon = { uart = "cdc", speed = 115200 }, > > in boards/known/mizar32[ab].lua but "lua build_elua.lua mizar32b" > > doesn't define BUILD_USB_CDC in the generated file > > boards/headers/board_mizar32b.h > > > > For what it's worth, you can see whether USB CDC support is > > included in the binary using: > > nm elua_lua_mizar32b.elf | grep usb_init > > > > I'm not sure how to fix this: if it's obvious to someone who knows the > > new build system, please go ahead and fix mizar32a and b. If not, I'll > > have another look at it and see if I can figure it out > > > > Cheers > > > > M > > _______________________________________________ > > eLua-dev mailing list > > [hidden email] > > https://lists.berlios.de/mailman/listinfo/elua-dev > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
> The branch is in https://github.com/ecdr/elua
> Had already submitted a pull request on that branch, so added this to it. > > I don't have the right compiler to build the mizar32, but > adding cdc = true > included BUILD_USB_CDC in the header file. and the USB CDC driver gets compiled into the binary. The other changes all look OK, so +1 to merge these M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On 11/05/2014, Martin Guy <[hidden email]> wrote:
>> The branch is in https://github.com/ecdr/elua >> Had already submitted a pull request on that branch, so added this to it. >> >> I don't have the right compiler to build the mizar32, but >> adding cdc = true >> included BUILD_USB_CDC in the header file. > > and the USB CDC driver gets compiled into the binary. Richard, can you see if this fixes your problems? When talking to Linux, the USB CDC thing takes about 8 seconds to complete the initial negotiation with the LInux kernel before the device appears in /dev. Non idea why. I also remember that Virtual timers must be enabled, as the VTMR interrupt is used by the USB subsystem, and you can reduce the USB startup time by increasing the VTMR_HZ from 10 to, say, 100 Hz: config = { vtmr = { num = 4, freq = 100 }, Does this help? M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
I've merged that pull request. On Sun, May 11, 2014 at 5:31 AM, Martin Guy <[hidden email]> wrote:
James Snyder
ph: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
Hi all,
Looks like after including cdc = true it finally works and I have a lua shell! Thanks all for your help. I see it is in the manual but I had been using the mizar32 as a starting point so hadn't seen that. It is good that this board is fixed as well now. By the way, I had earlier found out about increasing the vtmr frequency. Regards, -- Richard Graham On 05/11/2014 03:37 AM, Martin Guy wrote: > On 11/05/2014, Martin Guy <[hidden email]> wrote: >>> The branch is in https://github.com/ecdr/elua >>> Had already submitted a pull request on that branch, so added this to it. >>> >>> I don't have the right compiler to build the mizar32, but >>> adding cdc = true >>> included BUILD_USB_CDC in the header file. >> >> and the USB CDC driver gets compiled into the binary. > > Richard, can you see if this fixes your problems? > > When talking to Linux, the USB CDC thing takes about 8 seconds to > complete the initial negotiation with the LInux kernel before the > device appears in /dev. Non idea why. I also remember that Virtual > timers must be enabled, as the VTMR interrupt is used by the USB > subsystem, and you can reduce the USB startup time by increasing the > VTMR_HZ from 10 to, say, 100 Hz: > > config = { > vtmr = { num = 4, freq = 100 }, > > Does this help? > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On 12/05/2014, Richard Graham <[hidden email]> wrote:
> Hi all, > > Looks like after including cdc = true it finally works and I have a lua > shell! Thanks all for your help. I see it is in the manual but I had > been using the mizar32 as a starting point so hadn't seen that. It sounds like the build system could either check for console=cdc and not cdc=true and emit an error, or automatically add cdc=true when console=cdc, as preferred, to avoid this form of brakage in future M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Richard Graham
Adding something like the following to one of the .c files would at least give an error message. (Works with gcc, might need adaptation for other compilers.) #if (CON_UART_ID == CDC_UART_ID) && !defined(BUILD_USB_CDC) #error Console directed to USB, but USB CDC not being built. Add cdc=true to board file. #endif Haven't thought about best place to put it. Could put it in platform.c for those platforms which support USB CDC. Or could put it in common.c or common_uart.c > ----- Original Message ----- > From: Martin Guy > Sent: 05/13/14 01:01 AM > To: eLua Users and Development List (www.eluaproject.net) > Subject: Re: [eLua-dev] CDC on Avr32uc3 > > On 12/05/2014, Richard Graham <[hidden email]> wrote: > > Hi all, > > > > Looks like after including cdc = true it finally works and I have a lua > > shell! Thanks all for your help. I see it is in the manual but I had > > been using the mizar32 as a starting point so hadn't seen that. > > It sounds like the build system could either check for console=cdc and > not cdc=true and emit an error, or automatically add cdc=true when > console=cdc, as preferred, to avoid this form of brakage in future > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Tue, May 13, 2014 at 7:27 PM, <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hello elua people,
It looks like I am not 100% out of the woods yet with USB CDC. While it works sometimes, I am now most of the time getting an error "device descriptor read/64, error -110" and the device is not enumerating. This error seems to be for USB overcurrent. My device is self-powered so I don't think this can be real, and also my simple usb cdc test program continues to work perfectly. I noticed in the EVK board header files define USB_OVERCURRENT_DETECT_PIN and some other USB related things that are not done in the Mizar32 headers. I am wondering if there are some other required things that have not been copied over. I am guessing that I might be picking up noise on some pin which is triggering the overcurrent detect? I did try manually setting the overcurrent detect pin to something low and high but it didn't make any difference. My device simply has the vbus, dp, dm and gnd connected as per the atmal guidelines. I can't seem to stop this happening anymore but I am using the exact same code which worked before. Again, any suggestions greatly appreciated! -- Richard On 05/13/2014 11:41 AM, Bogdan Marinescu wrote: > > > > On Tue, May 13, 2014 at 7:27 PM, <[hidden email] <mailto:[hidden email]>> wrote: > > > Adding something like the following to one of the .c files would at > least give an error message. > (Works with gcc, might need adaptation for other compilers.) > > #if (CON_UART_ID == CDC_UART_ID) && !defined(BUILD_USB_CDC) > #error Console directed to USB, but USB CDC not being built. Add > cdc=true to board file. > #endif > > Haven't thought about best place to put it. > Could put it in platform.c for those platforms which support USB CDC. > Or could put it in common.c or common_uart.c > > > https://github.com/elua/elua/blob/master/inc/validate.h > > > > > > > ----- Original Message ----- > > From: Martin Guy > > Sent: 05/13/14 01:01 AM > > To: eLua Users and Development List (www.eluaproject.net > <http://www.eluaproject.net>) > > Subject: Re: [eLua-dev] CDC on Avr32uc3 > > > > On 12/05/2014, Richard Graham <[hidden email]> wrote: > > > Hi all, > > > > > > Looks like after including cdc = true it finally works and I > have a lua > > > shell! Thanks all for your help. I see it is in the manual but I had > > > been using the mizar32 as a starting point so hadn't seen that. > > > > It sounds like the build system could either check for console=cdc and > > not cdc=true and emit an error, or automatically add cdc=true when > > console=cdc, as preferred, to avoid this form of brakage in future > > > > M > > _______________________________________________ > > eLua-dev mailing list > > [hidden email] <mailto:[hidden email]> > > https://lists.berlios.de/mailman/listinfo/elua-dev > > _______________________________________________ > eLua-dev mailing list > [hidden email] <mailto:[hidden email]> > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On 14/05/2014, Richard Graham <[hidden email]> wrote:
> It looks like I am not 100% out of the woods yet with USB CDC. > While it works sometimes, I am now most of the time getting an error > "device descriptor read/64, error -110" and the device is not > enumerating. This error seems to be for USB overcurrent. My device is > self-powered so I don't think this can be real, and also my simple usb > cdc test program continues to work perfectly. Hum. This is not a behaviour we have seen on Mizar32. The AVR32UC3A datasheet has stuff about self-power and bus-power and some schematics at http://www.atmel.com/dyn/resources/prod_documents/doc32058.pdf#500 (page 500) I don't know if their 39 ohm resistors make a difference... There only seems to be one passing mention of the overcurrent in the datasheet, on p.553, though not enough to understand anything about how it works or how to enable/disable/fool it. > I noticed in the EVK board header files define > USB_OVERCURRENT_DETECT_PIN and some other USB related things that are > not done in the Mizar32 headers. I am wondering if there are some other > required things that have not been copied over. I see this also defined in eLua's EVK1100 and EVK1101 files, though it is never used in eLua. > I am guessing that I might be picking up noise on some pin which is > triggering the overcurrent detect? I did try manually setting the > overcurrent detect pin to something low and high but it didn't make any > difference. My device simply has the vbus, dp, dm and gnd connected as > per the atmal guidelines. I can't seem to stop this happening anymore > but I am using the exact same code which worked before. From what you say, that a simple example works but a larger one doesn't, it does sounds like electrical noise or an inadequate power supply. For the latter, can you try powering it from some beefy PSU, such as as ATX PSU of a PC, and see if that makes a difference? M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by BogdanM
On 13/05/2014, Bogdan Marinescu <[hidden email]> wrote:
> On Tue, May 13, 2014 at 7:27 PM, <[hidden email]> wrote: >> Adding something like the following to one of the .c files would at least >> give an error message. >> >> #if (CON_UART_ID == CDC_UART_ID) && !defined(BUILD_USB_CDC) >> #error Console directed to USB, but USB CDC not being built. Add >> cdc=true >> to board file. >> #endif >> >> Haven't thought about best place to put it. > > https://github.com/elua/elua/blob/master/inc/validate.h Done, thanks. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
Hi Martin,
Just a quick update on my USB problem. No solution as yet. But to answer your question: I do have it connected up with the resistors as specified. I am actually using a UC3B0512 chip. My power supply should be more than adequate and I have also tried looking at the micro power line, no voltage drop at all as it boots up or anything like that. It seems elua is otherwise continuing to run fine as I can flash leds after the console has been initialized. I noticed some mizar specific code in platform.c (line 226, probably not the best place for this..) and tried doing the same thing and also pulling up various lines that might be related but it doesn't make any difference. It's really weird that this has worked a few times but with the same code doesn't seem to work at all for the last few days. Meanwhile my simple example is still fine. I've also asked about this on the avr forums to see if anyone has any ideas. Thanks again, -- Richard On 05/16/2014 05:10 AM, Martin Guy wrote: > On 14/05/2014, Richard Graham <[hidden email]> wrote: >> It looks like I am not 100% out of the woods yet with USB CDC. >> While it works sometimes, I am now most of the time getting an error >> "device descriptor read/64, error -110" and the device is not >> enumerating. This error seems to be for USB overcurrent. My device is >> self-powered so I don't think this can be real, and also my simple usb >> cdc test program continues to work perfectly. > > Hum. This is not a behaviour we have seen on Mizar32. > The AVR32UC3A datasheet has stuff about self-power and bus-power and > some schematics at > http://www.atmel.com/dyn/resources/prod_documents/doc32058.pdf#500 (page 500) > I don't know if their 39 ohm resistors make a difference... > > There only seems to be one passing mention of the overcurrent in the > datasheet, on p.553, though not enough to understand anything about > how it works or how to enable/disable/fool it. > >> I noticed in the EVK board header files define >> USB_OVERCURRENT_DETECT_PIN and some other USB related things that are >> not done in the Mizar32 headers. I am wondering if there are some other >> required things that have not been copied over. > > I see this also defined in eLua's EVK1100 and EVK1101 files, though it > is never used in eLua. > >> I am guessing that I might be picking up noise on some pin which is >> triggering the overcurrent detect? I did try manually setting the >> overcurrent detect pin to something low and high but it didn't make any >> difference. My device simply has the vbus, dp, dm and gnd connected as >> per the atmal guidelines. I can't seem to stop this happening anymore >> but I am using the exact same code which worked before. > > From what you say, that a simple example works but a larger one > doesn't, it does sounds like electrical noise or an inadequate power > supply. > For the latter, can you try powering it from some beefy PSU, such as > as ATX PSU of a PC, and see if that makes a difference? > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
Just a bit of extra information about this issue I am having. Comparing the USB packets between my working example and elua, it seems that what is happening is that the response to the request for the device descriptor is being truncated to 64 bytes whereas it needs to be 82 bytes. It also takes 5 seconds after requested to send this data whereas it is sent straight away with the working example. So maybe elua is just truncating everything to 64 bytes. I've spent a lot of time looking through the code but can't see anything that could cause this. -- Richard On 05/19/2014 12:50 PM, Richard Graham wrote: > Hi Martin, > > Just a quick update on my USB problem. No solution as yet. But to answer > your question: > > I do have it connected up with the resistors as specified. I am actually > using a UC3B0512 chip. My power supply should be more than adequate and > I have also tried looking at the micro power line, no voltage drop at > all as it boots up or anything like that. It seems elua is otherwise > continuing to run fine as I can flash leds after the console has been > initialized. > > I noticed some mizar specific code in platform.c (line 226, probably not > the best place for this..) and tried doing the same thing and also > pulling up various lines that might be related but it doesn't make any > difference. > > It's really weird that this has worked a few times but with the same > code doesn't seem to work at all for the last few days. Meanwhile my > simple example is still fine. I've also asked about this on the avr > forums to see if anyone has any ideas. > > Thanks again, > > -- > Richard > > > > On 05/16/2014 05:10 AM, Martin Guy wrote: >> On 14/05/2014, Richard Graham <[hidden email]> wrote: >>> It looks like I am not 100% out of the woods yet with USB CDC. >>> While it works sometimes, I am now most of the time getting an error >>> "device descriptor read/64, error -110" and the device is not >>> enumerating. This error seems to be for USB overcurrent. My device is >>> self-powered so I don't think this can be real, and also my simple usb >>> cdc test program continues to work perfectly. >> >> Hum. This is not a behaviour we have seen on Mizar32. >> The AVR32UC3A datasheet has stuff about self-power and bus-power and >> some schematics at >> http://www.atmel.com/dyn/resources/prod_documents/doc32058.pdf#500 (page 500) >> I don't know if their 39 ohm resistors make a difference... >> >> There only seems to be one passing mention of the overcurrent in the >> datasheet, on p.553, though not enough to understand anything about >> how it works or how to enable/disable/fool it. >> >>> I noticed in the EVK board header files define >>> USB_OVERCURRENT_DETECT_PIN and some other USB related things that are >>> not done in the Mizar32 headers. I am wondering if there are some other >>> required things that have not been copied over. >> >> I see this also defined in eLua's EVK1100 and EVK1101 files, though it >> is never used in eLua. >> >>> I am guessing that I might be picking up noise on some pin which is >>> triggering the overcurrent detect? I did try manually setting the >>> overcurrent detect pin to something low and high but it didn't make any >>> difference. My device simply has the vbus, dp, dm and gnd connected as >>> per the atmal guidelines. I can't seem to stop this happening anymore >>> but I am using the exact same code which worked before. >> >> From what you say, that a simple example works but a larger one >> doesn't, it does sounds like electrical noise or an inadequate power >> supply. >> For the latter, can you try powering it from some beefy PSU, such as >> as ATX PSU of a PC, and see if that makes a difference? >> >> M >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |