CDC on Avr32uc3
Locked
12
12
|
Hi - Just chiming in here, though I haven't worked with AVR32 USB functionality much, but have worked with CDC on some other platforms. Have you checked that the platform_cdc_timer_handler and thus usb_device_task is indeed getting called at the expected rate (I saw some earlier discussion about frequency). The control endpoint has a max size of 64 bytes and maybe sends the first part of the descriptor but doesn't follow up?
Also is your working example AVR's CDC example? It looks like this is what usb-cdc.c is based on. Best. -jsnyder On Mon, May 19, 2014 at 7:37 PM, Richard Graham <[hidden email]> wrote: Hi, James Snyder
ph: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi James,
Thanks for the tip. I set an led to toggle when platform_cdc_timer_handler is called and it seems to just turn on occasionally but I am assuming it should be running at some kHz which it is definitely not so that might be the problem. Will have to try and figure out how often this is supposed to run and where that is set up. My working example is based on the CDC example with just a few changes for my clock setup and some simple code to toggle an led on certain keypresses. Thanks, -- Richard On 05/20/2014 10:25 AM, James Snyder wrote: > Hi - > > Just chiming in here, though I haven't worked with AVR32 USB > functionality much, but have worked with CDC on some other platforms. > > Have you checked that the platform_cdc_timer_handler and thus > usb_device_task is indeed getting called at the expected rate (I saw > some earlier discussion about frequency). The control endpoint has a > max size of 64 bytes and maybe sends the first part of the descriptor > but doesn't follow up? > > Also is your working example AVR's CDC example? It looks like this is > what usb-cdc.c is based on. > > Best. > > -jsnyder > > > On Mon, May 19, 2014 at 7:37 PM, Richard Graham <[hidden email] > <mailto:[hidden email]>> wrote: > > 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] <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] <mailto:[hidden email]> > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > > -- > James Snyder > ph: (847) 448-0386 > > > _______________________________________________ > 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 |
|
|
Ok, it looks like I have it working reliably at last.
Seems the problem was I had defined a 32768 Hz oscillator which I don't have. I did notice a few potential issues when going through all the code which I will try to note down and share later. -- Richard On 05/20/2014 12:28 PM, Richard Graham wrote: > Hi James, > > Thanks for the tip. I set an led to toggle when > platform_cdc_timer_handler is called and it seems to just turn on > occasionally but I am assuming it should be running at some kHz which it > is definitely not so that might be the problem. Will have to try and > figure out how often this is supposed to run and where that is set up. > > My working example is based on the CDC example with just a few changes > for my clock setup and some simple code to toggle an led on certain > keypresses. > > Thanks, > -- > Richard > > > On 05/20/2014 10:25 AM, James Snyder wrote: >> Hi - >> >> Just chiming in here, though I haven't worked with AVR32 USB >> functionality much, but have worked with CDC on some other platforms. >> >> Have you checked that the platform_cdc_timer_handler and thus >> usb_device_task is indeed getting called at the expected rate (I saw >> some earlier discussion about frequency). The control endpoint has a >> max size of 64 bytes and maybe sends the first part of the descriptor >> but doesn't follow up? >> >> Also is your working example AVR's CDC example? It looks like this is >> what usb-cdc.c is based on. >> >> Best. >> >> -jsnyder >> >> >> On Mon, May 19, 2014 at 7:37 PM, Richard Graham <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> 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] <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] <mailto:[hidden email]> >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> >> >> >> -- >> James Snyder >> ph: (847) 448-0386 >> >> >> _______________________________________________ >> 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 Tue, May 20, 2014 at 8:04 PM, Richard Graham <[hidden email]> wrote: Ok, it looks like I have it working reliably at last. Great! I did notice a few potential issues when going through all the code We'd be happy to integrate fixes or patches where appropriate. Best. -jsnyder
James Snyder
ph: (847) 448-0386 _______________________________________________ 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 |