• AVR Freaks

AnsweredHot!Why can't 192 bytes be transmitted? (CDC, Harmony 2.06 USB & PIC32MZ

Author
DominusT
Super Member
  • Total Posts : 1401
  • Reward points : 0
  • Joined: 2005/07/22 08:31:18
  • Status: offline
2020/05/28 16:10:44 (permalink)
0

Why can't 192 bytes be transmitted? (CDC, Harmony 2.06 USB & PIC32MZ

Hi.
 
I'm using the cdc_com_port_single example of Harmony 2.06 with the PIC32MZ device.
 
I use the USB port emulating a COM to configure my hardware.
 
During several months it has worked correctly until today we create a new configuration that by coincidence is 192 bytes.
When sending that frame from the host to the MCU, there is no response, after reviewing many things, it was determined that it doesn't work for such amount of bytes sent.


It works correctly for 191 or 193 bytes. A cumbersome solution could be to add an extra byte to our frame.
 
My questions are:
 
Is there a way to solve this problem?
 
Could it happen with another number of bytes?
 
Any comments or suggestions are welcome.
#1
ric
Super Member
  • Total Posts : 27595
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: offline
Re: Why can't 192 bytes be transmitted? (CDC, Harmony 2.06 USB & PIC32MZ 2020/05/28 16:29:30 (permalink)
5 (2)
I suspect you would get the same problem on any exact multiple of 64.
Any extra empty frame (zero bytes) should flush it.

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#2
DominusT
Super Member
  • Total Posts : 1401
  • Reward points : 0
  • Joined: 2005/07/22 08:31:18
  • Status: offline
Re: Why can't 192 bytes be transmitted? (CDC, Harmony 2.06 USB & PIC32MZ 2020/05/28 18:14:40 (permalink)
0
ric
I suspect you would get the same problem on any exact multiple of 64.
Any extra empty frame (zero bytes) should flush it.


I'm not a USB expert, but I would like to know if I can avoid sending that extra byte for frames of length multiple of 64.
#3
ric
Super Member
  • Total Posts : 27595
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: offline
Re: Why can't 192 bytes be transmitted? (CDC, Harmony 2.06 USB & PIC32MZ 2020/05/28 18:29:03 (permalink) ☼ Best Answerby DominusT 2020/05/29 16:32:41
5 (3)
Long time since I've looked through the USB spec, but as I recall, that is how it strings multiple frames together.
Exactly 64 means "more to come", and it requires another zero length packet to indicate "that's all for now".
That's what is happening at the lowest level. Higher level drivers are free to implement timeouts etc. to force termination.
 
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#4
DominusT
Super Member
  • Total Posts : 1401
  • Reward points : 0
  • Joined: 2005/07/22 08:31:18
  • Status: offline
Re: Why can't 192 bytes be transmitted? (CDC, Harmony 2.06 USB & PIC32MZ 2020/05/28 18:33:26 (permalink)
0
ric
Long time since I've looked through the USB spec, but as I recall, that is how it strings multiple frames together.
Exactly 64 means "more to come", and it requires another zero length packet to indicate "that's all for now".
That's what is happening at the lowest level. Higher level drivers are free to implement timeouts etc. to force termination.
 


But emulating a COM implies that any number of bytes will be transmitted. The question would be what does a commercial USB to RS232 converter do when it transmits a 64 byte frame. I think an 'extra' byte doesn't come when that happens.
 
#5
Antipodean
Super Member
  • Total Posts : 1855
  • Reward points : 0
  • Joined: 2008/12/09 10:19:08
  • Location: Didcot, United Kingdom
  • Status: offline
Re: Why can't 192 bytes be transmitted? (CDC, Harmony 2.06 USB & PIC32MZ 2020/05/28 20:02:35 (permalink)
4.5 (4)
DominusT
ric
Long time since I've looked through the USB spec, but as I recall, that is how it strings multiple frames together.
Exactly 64 means "more to come", and it requires another zero length packet to indicate "that's all for now".
That's what is happening at the lowest level. Higher level drivers are free to implement timeouts etc. to force termination.
 


But emulating a COM implies that any number of bytes will be transmitted. The question would be what does a commercial USB to RS232 converter do when it transmits a 64 byte frame. I think an 'extra' byte doesn't come when that happens.
 

 
IIRC from using the MLA USB Code on a PIC24 there was a function to send a 0 length packet. The 0 length packet indicates the end of "this transfer" and is a purely housekeeping function within the USB, and doesn't send an extra byte down the serial port.
 

Do not use my alias in your message body when replying, your message will disappear ...

Alan
#6
DominusT
Super Member
  • Total Posts : 1401
  • Reward points : 0
  • Joined: 2005/07/22 08:31:18
  • Status: offline
Re: Why can't 192 bytes be transmitted? (CDC, Harmony 2.06 USB & PIC32MZ 2020/05/29 05:31:57 (permalink)
0
I was finding out how a USB to RS232 serial converter works and it is not a simple bridge between the traveling bytes, as I thought. There is a communication frame in which what the user wants to send and receive is encapsulated, in this way for the user the sending and receiving of data is 'transparent'.
 
If the frame length is a multiple of 64, an extra byte is added as indicated by @ric, obviously after the frame arrives at its destination, the encapsulation and the extra byte (if any) are removed, and in that way only the data that was sent remains.
#7
MisterHemi
Super Member
  • Total Posts : 255
  • Reward points : 0
  • Joined: 2017/11/02 12:24:21
  • Location: Commerce, CA USA
  • Status: offline
Re: Why can't 192 bytes be transmitted? (CDC, Harmony 2.06 USB & PIC32MZ 2020/05/29 16:10:15 (permalink)
5 (1)
With High Speed USB endpoint 0 always sends packets 64 bytes in length but the other endpoints can send as few as 8 bytes.
 
Usually even length packets indicate there is more data to come. A zero length packet tells the host there is no more data.
 
If you want to see a simplified USB CDC example for the PIC32MZ look at my example here:
github.com/misterhemi/PIC32MZ
 
It's titled: PIC32MZ_drop-in_USB_CDC_ACM_v2.X.zip
 
It's just basic USB without Harmony but it should be easier to understand.
post edited by MisterHemi - 2020/05/29 16:11:56

My configuration:
MacBook Pro (Retina, 15-inch, Mid 2015) with MacOS Mojave (10.14.6) and MPLAB X IDE v5.30
 
Curiosity PIC32MZ EF 1 & 2, PIC24F Curiosity, XPRESS EVAL BOARD (PIC16F18855), SAMA5D3 Xplained and various custom boards.
#8
DominusT
Super Member
  • Total Posts : 1401
  • Reward points : 0
  • Joined: 2005/07/22 08:31:18
  • Status: offline
Re: Why can't 192 bytes be transmitted? (CDC, Harmony 2.06 USB & PIC32MZ 2020/05/29 16:32:32 (permalink)
0
MisterHemi
With High Speed USB endpoint 0 always sends packets 64 bytes in length but the other endpoints can send as few as 8 bytes.
 
Usually even length packets indicate there is more data to come. A zero length packet tells the host there is no more data.
 
If you want to see a simplified USB CDC example for the PIC32MZ look at my example here:
github.com/misterhemi/PIC32MZ
 
It's titled: PIC32MZ_drop-in_USB_CDC_ACM_v2.X.zip
 
It's just basic USB without Harmony but it should be easier to understand.


Thank you very much for the suggestion, but I have talked to the person who develops the software and she has added an extra byte when the frame length is a multiple of 64, we have done several tests and it seems to work correctly, so I think the problem is has fixed.
#9
MisterHemi
Super Member
  • Total Posts : 255
  • Reward points : 0
  • Joined: 2017/11/02 12:24:21
  • Location: Commerce, CA USA
  • Status: offline
Re: Why can't 192 bytes be transmitted? (CDC, Harmony 2.06 USB & PIC32MZ 2020/05/29 17:03:18 (permalink)
0
DominusT
MisterHemi
With High Speed USB endpoint 0 always sends packets 64 bytes in length but the other endpoints can send as few as 8 bytes.
 
Usually even length packets indicate there is more data to come. A zero length packet tells the host there is no more data.
 
If you want to see a simplified USB CDC example for the PIC32MZ look at my example here:
github.com/misterhemi/PIC32MZ
 
It's titled: PIC32MZ_drop-in_USB_CDC_ACM_v2.X.zip
 
It's just basic USB without Harmony but it should be easier to understand.


Thank you very much for the suggestion, but I have talked to the person who develops the software and she has added an extra byte when the frame length is a multiple of 64, we have done several tests and it seems to work correctly, so I think the problem is has fixed.




You're welcome!

My configuration:
MacBook Pro (Retina, 15-inch, Mid 2015) with MacOS Mojave (10.14.6) and MPLAB X IDE v5.30
 
Curiosity PIC32MZ EF 1 & 2, PIC24F Curiosity, XPRESS EVAL BOARD (PIC16F18855), SAMA5D3 Xplained and various custom boards.
#10
Jump to:
© 2020 APG vNext Commercial Version 4.5