 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
| Anyone successfully used usb_puts, with > 256bytes of dat |
 Posted: Wed Sep 30, 2015 8:12 am |
 |
|
Hi,
Have USB setup with an MSD descriptor. Currently on a PIC1826J50, but am also working on a PIC24 version. All the initial enumeration works, device recognised as mass storage, and a disk drive appears in Device Manager.
However when it gets to sending actual sectors of data, something odd is happening. Using a USB sniffer, I'm seeing the reply arriving as 333bytes of data. Now the last 13bytes are the CSW (this is the 'tail' you put onto the data carrying the marker to identify it, and the tag, that identifies the request it is a reply 'to'). Data in this matches the CBW, that made the request.
Problem is there should be 512 bytes of data in front of the CSW, and instead there are 320 bytes!.
Now can't slow things down too much or stuff in the USB starts to fail. However added a single character output to serial each time a 64byte packet is output on the USB as a reply to this particular CBW, and lo an behold 8 packets are apparently being output, then the CSW. But the sniffer only sees 320 bytes! (5 packets) then the CSW....
Ugh.
So question is whether anyone has used usb_puts, sending a block over 256 bytes on a PIC18?. The biggest example sends 256 bytes (the scope), and the older puts implementation was limited to 8bit counts, but the current version says it supports 16bit counts, and the code looks OK on an initial scan, but I'm still only seeing 320 bytes...
| Code: |
//transmission call
usb_puts(0x1,msd_sect,512,100);
//buffer declaration
uint8_t msd_sect[512]; //512 byte sector buffer
|
After the reply is seen, there is a one minute pause, and then the host retries, and I give an identical reply!.
Currently using 5.048, and .049 (started on 048, and since I had to add code to usb.c for handling the class specific request for an MSD (MSD_RESET, and GET_MAX_LUN - both work the device is reporting it's size correctly, had been sticking with the compiler I started on - however tries 5.049 'in case').
So has anyone used this function or do I need to re-write this?. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Sep 30, 2015 9:49 am |
|
|
| Quote: | | But the sniffer only sees 320 bytes! (5 packets) |
Could this be it ?
http://vusb-analyzer.sourceforge.net/tutorial.html
| Quote: | usb.analyzer.maxLine = <number of 16-byte lines>
This is optional, but we'll increase the length of the payload data that we log for each USB packet. By default, only 80 bytes (5 hex dump lines) of data are logged for each packet. To see the entire contents, we'll increase this to 8192. This will make your log files significantly bigger, so if you don't need the full packet contents you can set this to a small number to decrease logging overhead. |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Wed Sep 30, 2015 2:22 pm |
|
|
No, I did the basic test of putting a USB memory stick in and running the same test code, and it correctly reports 525 bytes.
Should have said this. 
I'm beginning to suspect that the large transmission without using ping-pong (the CCS USB code does not use this), is resulting in a timeout.
Now looking to rewrite the core CCS functions to use ping-pong. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Thu Oct 01, 2015 11:10 am |
|
|
It is timing that is the problem.
Have started on a ping pong version of the drivers for EP1 (set the code up to only use ping pong on the endpoints>0 so the existing EP0 code can be retained). Not quite right yet, but just successfully had over 4KB as a single transaction without problems. So for anyone trying this in the future the existing CCS code is just not fast enough for a bulk mode device shifting large quantities.... :( |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
