| Author |
Message |
|
|
Posted: Dec 01, 2011 - 11:45 AM |
|

Joined: Mar 17, 2005
Posts: 1307
Location: Stockholm, Sweden
|
|
Nope, 0x10 did not change much. Making it 0x00 did make it a lot worse thou. Guess the interrupt endpoint takes all the packages.
Thanks for taking your time with this!
If you want to use your interface in any other way, do a test transferring 5120 bytes in a DMA transfer. Let it finish and loop that 100 or 1000 times. Mine fails 1-2/100 or so. |
|
|
| |
|
|
|
|
|
Posted: Dec 01, 2011 - 02:43 PM |
|

Joined: Mar 17, 2005
Posts: 1307
Location: Stockholm, Sweden
|
|
| I got the answer from atmel now about this problem. They say I should upgrade to the newer USB stack and told me to read the migration PDF about it. The PDF sais that too much has changed, start over som one of the examples. Doh! |
|
|
| |
|
|
|
|
|
Posted: Dec 01, 2011 - 02:58 PM |
|

Joined: Aug 25, 2011
Posts: 392
Location: Europe
|
|
Have you been using the ASF 2.x all along or have you been trying with 1.7? With 1.7 it should’ve worked the same as it did for me. I guess “upgrade to the newest version” is the default answer if they have no idea and don’t want to spend too much time on it...
If you’re starting a new project, using the newest ASF is probably a good choice either way.
I’m not going to upgrade due to the interrupt-related changes I implemented and with the new AVR Studio 5 they chucked the Linux support.
Good luck with the new ASF. |
|
|
| |
|
|
|
|
|
Posted: Dec 16, 2011 - 08:13 AM |
|

Joined: Mar 17, 2005
Posts: 1307
Location: Stockholm, Sweden
|
|
I have been using ASF 1.7 all the time, and the program is developed for 1 year now, so it is quite a lot of code. Porting all to 2.x is a lot of work. And will that fix the problem??
I did a quick test with 2.x to see if they increased the transfer speed. But it is as low in the 2.x example as it was in the 1.7 example when I started. And that is very very slow.
Back to why Im posting right now. Is anyone else experiencing that he transfer fail rate is depending on computer and operating system a lot? I am developing on a XP 64, but have a Win7 to test on too. And in the lab we have Vistas too. At my desk, I get all transfers to work without fail at all on both XP64 and Win7, but in the lab we have one computer which never fails, and a bunch that fails from rarely to very often. And there Win7 never works.
Anyone have any experiance from this? Any thought? |
|
|
| |
|
|
|
|
|
Posted: Dec 16, 2011 - 10:05 AM |
|

Joined: Aug 25, 2011
Posts: 392
Location: Europe
|
|
Are you still referring to the problem with transfer sizes that are multiples of 64 bytes?
If not, here are my OS experiences:
I’m developing on Linux 64 bit and porting some programs to Cygwin 32 bit as well.
Linux 64 bit: flawless
Windows 7 64 bit (with Cygwin 32 bit): no transfer problems
Windows XP 32 bit (with Cygwin 32 bit): only one unknown transfer freeze (I blame Matlab for that)
I’m only transferring packets smaller than 64 bytes, though, usually 8 or 25 bytes long. I have the UDDMA copy them into the USBB without the transfer end flag set if I have more than one to send, so it might end up sending 64 bytes in one USB packet. Then again I’m only using 512 byte HiSpeed endpoints.
Not sure if any of this helps. |
|
|
| |
|
|
|
|
|
Posted: Dec 16, 2011 - 11:44 AM |
|

Joined: Mar 17, 2005
Posts: 1307
Location: Stockholm, Sweden
|
|
I don't see any problems either when sending smaller packages. Its when I send larger packages many many times some of them fail.
I have packages that are 98 816 bytes and I send them at 30 Hz. The bytes are connected using transfer descriptors and UDDMA. On some computers the transfers never fail, on other it fails 1/5(?) of the tranfers.
Are there any configures for the PC side? Something I can do to give this transfer priority or remove/add buffers? |
|
|
| |
|
|
|
|
|
Posted: Dec 16, 2011 - 12:40 PM |
|

Joined: Aug 25, 2011
Posts: 392
Location: Europe
|
|
| AFAIK it’s not possible to change the receive buffer of the virtual serial port, but if you’re on Windows you could try changing your program’s process priority via the task manager. |
|
|
| |
|
|
|
|
|
Posted: Dec 16, 2011 - 01:15 PM |
|

Joined: Mar 17, 2005
Posts: 1307
Location: Stockholm, Sweden
|
|
| I have tried that, and it seems it can make things a bit better, but never go from not working perfectly to working perfectly. So on a computer which get receive errors, I still get them. |
|
|
| |
|
|
|
|
|
Posted: Dec 16, 2011 - 01:21 PM |
|

Joined: Aug 25, 2011
Posts: 392
Location: Europe
|
|
Have you checked what happens if your program doesn’t pick up incoming data quickly enough?
For me once the PC’s receive buffer is full the USB connection won’t transfer any more incoming data, causing the UDDMA to wait. Then my AVR32 program starts queuing data internally. Once I pick up some data on the PC, all transfers resume.
Maybe some part of this chain doesn’t work for you and the PC’s little 4k receive buffer overflows, causing data loss? Or maybe you’re not noticing a stalled transfer quickly enough and your AVR32 application starts losing data and things go bad? |
|
|
| |
|
|
|
|
|
Posted: Dec 16, 2011 - 02:35 PM |
|

Joined: Mar 17, 2005
Posts: 1307
Location: Stockholm, Sweden
|
|
| I have done tests regarding that. I have a LED that turns on when data is waiting for transmission. And a button on the unit that when I press, send one batch of data. And the LED can be on for a long while if I dont read, but as soon as I start reading, the data starts transmitting again without loosing data. So that seems to be working. |
|
|
| |
|
|
|
|
|
Posted: Feb 29, 2012 - 05:30 PM |
|

Joined: Mar 17, 2005
Posts: 1307
Location: Stockholm, Sweden
|
|
Has been spending another day on this issue. I ended up with setting the transfer descriptors the way that feels correct rather than what I understand from the datasheet. Only the last transfer descriptor is set up to end/close/finish the transmission. The others is just set to enable the transfer and load next descriptor in the end of its buffer. This far that change has given no more errors.
Another thing I took a look at was how I set up the SMC that the UDDMA reads from. It seems I have not done that correctly before. I have a feeling it used the default memory settings rather than what I set. Finaly I got the transmission rate to become much slower when I multiplied all delay states in the memory configuration by 10. Now that the settins are corrected and I devided all the delay settings by 10 instead, I get an incredible speed for the data transfer. I have not yet set the all delays to 0 (which might not always be the fastest setting) and already got transfer speeds of 62 MBit! I read in the datasheet that around 52 MBit would be about the fastest continous you could get. So that is a bit worrying. But it might be that the tests done for the datasheet uses the SDRAM that is used on any of the EVK:s and the one I have is infinitely fast in comparison to that.
At first I did not get any data, but had that 78 MBit speed (computer just read zeros). But after configuring the SMC correctly/better, I did get data. I have not checked yet that it is absolutely and always correct data. But it did look like the data I would normaly get and the amount of bytes is correct.
I thought that 32 MBit/s was maximum speed. But it seems that each micro frame can carry not 512 bytes, but 4096 bytes. So then 262 Mbit/s should be max. Not that the UC3A3 can have that throughput. |
|
|
| |
|
|
|
|
|
Posted: Mar 01, 2012 - 07:00 AM |
|

Joined: Mar 17, 2005
Posts: 1307
Location: Stockholm, Sweden
|
|
| I have been experimenting a little further now. Sending 9 836 600 bytes takes atleast 0.902 seconds. So thats about 87 Mbits/s. And it scales up quite well too. 98 366 000 bytes takes 9.644 seconds to transfer. |
|
|
| |
|
|
|
|
|
Posted: Mar 07, 2012 - 12:44 AM |
|

Joined: Mar 28, 2010
Posts: 127
Location: Palmerston North, New Zealand
|
|
Hi Agwanll,
Can I ask if you would post a summary of how you ended up configuring the USB, as I on occasion still seem to get dropped points, and this is a long post.
A complete summary would be outstanding....
Regards. |
|
|
| |
|
|
|
|
|
Posted: Mar 07, 2012 - 10:33 AM |
|

Joined: Mar 17, 2005
Posts: 1307
Location: Stockholm, Sweden
|
|
I have not for my self either made this summary. But this might help you at least a little. All these changes are done in the "device_cdc_task.c"-file. There are much more changes to that file, but most of that should be connected to my specific application code. This is not a guide on all you have to do to get it working. I have been programming this for a year.
I started with the USART CDC example ASF 1.7.
The USB settings:
Code:
void device_cdc_task_init(void) {
sof_cnt = 0;
Usb_enable_sof_interrupt();
}
void usb_set_configuration_action(void) {
Usb_enable_endpoint_bank_autoswitch(TX_EP);
}
void usb_sof_action(void) {
sof_cnt++;
}
In the main device_cdc_task loop I have this to push out data that might get stuck:
Code:
if (sof_cnt >= NB_MS_BEFORE_FLUSH) { //Flush buffer in Timeout
sof_cnt = 0;
if( 0 == Usb_nb_busy_bank(TX_EP) ) {
Usb_ack_in_ready_send(TX_EP);
}
}
Transfer descriptor creation:
Code:
typedef struct {
unsigned long int nextDescriptorAddress __attribute__ ((aligned (32)));
unsigned long int HSBAddress __attribute__ ((packed));
unsigned long int control __attribute__ ((packed));
}TransferDescriptor;
And setup:
Code:
replyTransferDescriptor.nextDescriptorAddress = (unsigned long int)NULL;
replyTransferDescriptor.HSBAddress = 0;
replyTransferDescriptor.control = 0;
I then have this for sending smaller messages where one transfer descriptor is enough. (65k bytes)
Code:
void sendMessage(void *txbuf, int messageLenght) {
replyTransferDescriptor.HSBAddress = (unsigned long int)txbuf;
replyTransferDescriptor.control = ((messageLenght) << 16) | AVR32_USBB_UXDMAX_CONTROL_DMAEND_EN_MASK | AVR32_USBB_UXDMAX_CONTROL_BUFF_CLOSE_IN_EN_MASK | AVR32_USBB_UXDMAX_CONTROL_CH_EN_MASK;
AVR32_USBB_UDDMAX_nextdesc(TX_EP) = (unsigned long int)&replyTransferDescriptor.nextDescriptorAddress; // Point at transfer descriptor
AVR32_USBB_UDDMAX_control(TX_EP) = AVR32_USBB_UXDMAX_CONTROL_LD_NXT_CH_DESC_EN_MASK; // Load that transfer descriptor
LED_On(LED0);
while ( (AVR32_USBB_UDDMAX_status(TX_EP) && AVR32_USBB_UXDMAX_STATUS_CH_EN_MASK) == 1 ) { // AVR32_USBB_UXDMAX_STATUS_CH_EN_MASK
LED_On(LED0);
};
LED_Off(LED0);
sof_cnt = 0;
Usb_ack_in_ready_send(TX_EP);
}
The "Usb_ack_in_ready_send(TX_EP);" should not be needed, but it does not work without it. Probably because there is a bug somewere else. It also does not work if I don't blink the leds when sending data as seen above. Should be possible to exchange it for a number of NOP:s or a delay. Don't know. |
|
|
| |
|
|
|
|
|
Posted: Mar 07, 2012 - 10:42 AM |
|

Joined: Mar 17, 2005
Posts: 1307
Location: Stockholm, Sweden
|
|
| Perhaps the sof counting and Usb_ack_in_ready_send(TX_EP); is not needed. I did some experiments now and it worked at least with just minimal testing. |
|
|
| |
|
|
|
|
|
Posted: Mar 07, 2012 - 08:43 PM |
|

Joined: Mar 28, 2010
Posts: 127
Location: Palmerston North, New Zealand
|
|
Hi Agwanll,
Exactly what I was after. I have been playing with it for about half as long as you have (as well as the USB OtG Host implementation as well) and like you I started with the CDC example. Can now do a code audit on my implementation and hopefully make it spot on.
Cheers
PS If u are ever in NZ, I'll buy u a beer. |
|
|
| |
|
|
|
|
|