• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 1477 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

USB Host configuration for ISO IN Transfers

1258021
Genius 5120 points
Other Parts Discussed in Thread: AM3352

Hi,

We are using AM3352 processor. When we connect a camera the ENDPOINT maximum packet size is reported as 0x1400. 

So, each packet length is 1024 and the camera is able to send three such packets per micro frame.

How we shall configure RXCSR for this type of configuration.

When I put analyzer I see that some times camera is sending one DATA0 per micro frame. In some scenarios it is sending DATA1 & DATA0 packets per micro frame.

Is this will be automatically handled in the hardware if we configure RXMAXP with 0x1400? We are using CPPI DMA. How the DMA knows how many packets/to offload. 

In case of DATA1 & DATA0 packets is interrupt generated per one packet / once for two packets?

Regards,

GSR

  • 0
    TI__Guru**** 393215 points

    Hi,

    I will forward this to the USB experts.

  • 0 in reply to Biser Gatchev-XID
    Genius 5120 points
    Hi Biser,

    Thanks for the reply & your time.

    Please do the needful.

    Regards,
    GSR
  • 0
    TI__Guru**** 168291 points

    GSR,

    I have not seen a USB camera which sends variable number of ISO packets per micro frame, so not sure what specific configuration is required to handle this, I will do a search and get you back on this.

    Regarding CPPI, the MUSB controller will generates DMA request for each received packet, so CPPI will transfer the packet. This will handle multiple ISO packets in a micro frame.

    1258021 said:
    In case of DATA1 & DATA0 packets is interrupt generated per one packet / once for two packets?

    I believe it will be two interrupts for this case, I will double check. But please note that the interrupt is only generated when CPPI finished transferring data from MUSB EP FIFO to DDR to notify application to consume the data. It is called CPPI RX Completion Interrupt.

    Is this on Linux? If so, what is the AMSDK version?

  • 0 in reply to Bin Liu
    TI__Guru**** 168291 points
    Please provide the descriptor information of the camera, using command 'lsusb -v -d <vid:pid>'.
  • 0 in reply to Bin Liu
    Genius 5120 points

    Hi,

    I will share the complete descriptor information as soon as possible.

    Regards,

    GSR

  • 0 in reply to Bin Liu
    Genius 5120 points

    Hi,

    We are not using latest SDK, when I run lsusb it says not supported / unknown command.

    Currently I see three problems with the camera

    1. One of the camera that we are using reports that it can send three packets per micro frame so BITS EP Max Pkat Size is 0x1400. But when I put analyzer and see that camera always sends only one packet with DATA0 PID. But when I connect the same camera to the PC, I see DATA2, DATA1, DATA0 packets and DATA1, DATA0 packets. Why I am worrying about this is camera sends 12-Bytes packets when we decode the second byte it says that packet is error packet. So, I am assuming that host is not requesting enough IN tokens with in a Micro Frame (AM3352 operating in High Speed mode)
    2. Lets says camera resolution set to 320 x 240 with 2-Bytes per pixel, so frame length = 153600. But, sometimes, I see that the frame length received is less than 153600, how to prevent this?
    3. On the display screen, we also observe frame split some times? why this happens even when we receive a frame length equals to 153600?

    Thank you for your time Bin Liu.

    Best Regards,

    GSR

  • 0 in reply to 1258021
    TI__Guru**** 168291 points

    1258021 said:
    We are not using latest SDK,

    What is the SDK version then? I have to know the exact SDK you use to know if you hit on any known issue in the kernel.

    1258021 said:
    when I run lsusb it says not supported / unknown command.

    It seems telling you are not using the filesystem provided in the SDK package. But you can connect the camera on PC and run lsusb to get the descriptor log.

    1258021 said:
    But when I put analyzer and see that camera always sends only one packet with DATA0 PID. But when I connect the same camera to the PC, I see DATA2, DATA1, DATA0 packets and DATA1, DATA0 packets.

    What is the test application? Does the video resolution is the same in both cases with the board and PC? The smaller resolution requires less data for each video frame. What is the length of each DATA0,1,2 packet?

    1258021 said:
    Why I am worrying about this is camera sends 12-Bytes packets when we decode the second byte it says that packet is error packet.

    second byte? I guess you meant second packet in a SOF - DATA1? I remembered the UVC packet has 12-bytes header, so 12-bytes packet tells there is no video data available from the camera. I read the UVC Specs a long time ago...

    1258021 said:
    Lets says camera resolution set to 320 x 240 with 2-Bytes per pixel, so frame length = 153600. But, sometimes, I see that the frame length received is less than 153600, how to prevent this?

    So this raw video format, right? Do you see the shorter frame on the bus or in your application? If on the bus, it is a camera problem, I am not sure how to fix this without replacing the camera. If the USB driver returns shorter packets to application, it should be the MUSB hw or sw issue, I recommend to test with latest SDK to ensure you have all driver fixes.

    Please also refer to wiki http://processors.wiki.ti.com/index.php/Sitara_Linux_MUSB_Issues for fixes after each SDK release.

    1258021 said:
    On the display screen, we also observe frame split some times? why this happens even when we receive a frame length equals to 153600?

    This could be display problem in your application. It is common issue when only use single display buffer - the display buffer has been updated with a new frame while LCDC is displaying the current frame.