Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
AgwanII
PostPosted: Dec 01, 2011 - 11:45 AM
Posting Freak


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.
 
 View user's profile Send private message  
Reply with quote Back to top
AgwanII
PostPosted: Dec 01, 2011 - 02:43 PM
Posting Freak


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!
 
 View user's profile Send private message  
Reply with quote Back to top
catweax
PostPosted: Dec 01, 2011 - 02:58 PM
Hangaround


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. Confused

Good luck with the new ASF.
 
 View user's profile Send private message  
Reply with quote Back to top
AgwanII
PostPosted: Dec 16, 2011 - 08:13 AM
Posting Freak


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?
 
 View user's profile Send private message  
Reply with quote Back to top
catweax
PostPosted: Dec 16, 2011 - 10:05 AM
Hangaround


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.
 
 View user's profile Send private message  
Reply with quote Back to top
AgwanII
PostPosted: Dec 16, 2011 - 11:44 AM
Posting Freak


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?
 
 View user's profile Send private message  
Reply with quote Back to top
catweax
PostPosted: Dec 16, 2011 - 12:40 PM
Hangaround


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.
 
 View user's profile Send private message  
Reply with quote Back to top
AgwanII
PostPosted: Dec 16, 2011 - 01:15 PM
Posting Freak


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.
 
 View user's profile Send private message  
Reply with quote Back to top
catweax
PostPosted: Dec 16, 2011 - 01:21 PM
Hangaround


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?
 
 View user's profile Send private message  
Reply with quote Back to top
AgwanII
PostPosted: Dec 16, 2011 - 02:35 PM
Posting Freak


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.
 
 View user's profile Send private message  
Reply with quote Back to top
AgwanII
PostPosted: Feb 29, 2012 - 05:30 PM
Posting Freak


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.
 
 View user's profile Send private message  
Reply with quote Back to top
AgwanII
PostPosted: Mar 01, 2012 - 07:00 AM
Posting Freak


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.
 
 View user's profile Send private message  
Reply with quote Back to top
daffniles
PostPosted: Mar 07, 2012 - 12:44 AM
Hangaround


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.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
AgwanII
PostPosted: Mar 07, 2012 - 10:33 AM
Posting Freak


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.
 
 View user's profile Send private message  
Reply with quote Back to top
AgwanII
PostPosted: Mar 07, 2012 - 10:42 AM
Posting Freak


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.
 
 View user's profile Send private message  
Reply with quote Back to top
daffniles
PostPosted: Mar 07, 2012 - 08:43 PM
Hangaround


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.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits