• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 676 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.

C6748 UPP Driver Reset Not Working?

Seth Weith-Glushko
Prodigy 20 points

Hi folks,

I figured I would try to save some heartache for myself and ask this question. I'm using the C6748 to interface with an FPGA using the UPP driver (DSP/BIOS 5.41.10.36 and PSP 1.30.01). We have it setup for bidirectional communication (Chan A receiving and Chan B transmitting). We are using the issue/reclaim model (3 buffers). The UPP driver is setup statically (through a TCF file). Everything works fine until we need to reset the UPP and reprogram the transfer parameters (to deal with differently sized data being transferred). The driver reset seems to work (returns SYS_OK when I issue a SIO_ctrl(uppInHandle, IOM_DEVICE_RESET, 0) command). But when I reissue the buffers, I always get a SYS_EBADIO (6) as a return value.

I've included the driver source into our project and from the looks of the channel instance, the queues holding the IOM packet information get cleared out and the UPP is reset (according to the system registers). However, with a little work, I've found that uppMdSubmitChan() is never called after executing the SIO_issue() command, which leads me to believe it is something upstream from the UPP driver.

Anybody else run into this or thoughts?

Thanks,

Seth

  • 0
    TI__Expert 5500 points

    Hello Seth,

    From your observations my first guess would be, the "SIO_Attrs" settings.

    Seth Weith-Glushko said:
    However, with a little work, I've found that uppMdSubmitChan() is never called after executing the SIO_issue() command, which leads me to believe it is something upstream from the UPP driver.

    In the application, just before the "SIO_create" is called, the 'SIO_Attrs' structure is initialized. If you refer the BIOS Userguide,

    struct SIO_Attrs {   /* stream attributes */
    Int nbufs;                 /* number of buffers */
    Int segid;                 /* buffer segment ID */
    size_t align;            /* buffer alignment */
    Bool flush;              /* TRUE->don't block in DEV_idle */
    Uns model;            /* SIO_STANDARD,SIO_ISSUERECLAIM */
    Uns timeout;          /* passed to DEV_reclaim */
    SIO_Callback        /*callback; initialize callback in DEV_Obj */
    } SIO_Attrs;

    'nbufs' specifies the number of buffers to prepare for. The default value of 'nbufs' is 2. In the SIO_ISSUERECLAIM usage model, nbufs is the maximum number of buffers that can be outstanding (that is, issued but not reclaimed) at any point in time. I guess you have set it to 3. Try increasing this value and check. For Ex: nbufs=10;

    Hope this solves the issue.

     

    Best Regards,

    Raghavendra

  • 0 in reply to Raghavendra Maddikery
    Prodigy 20 points

    Thanks for replying Raghavendra. I guess my understanding of the SIO system is that if I increase the number of buffers and then call SIO_issue to new buffer locations (with new UPP DMA parameters) then the original 3 buffers that have been issued are still in the queue and any subsequent transfers from the FPGA will use those old locations. Additionally, as I keep reissuing the buffers, I will hit the nbufs limit. Is my understanding correct?

    What I'm looking for is a way to "un-issue" buffers and then re-issue them with different UPP DMA parameters (for example, instead of receiving 2048 bytes of information, I'm receiving 5192 bytes).

    Thanks,

    Seth