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.

UPP driver buffer size limitation

Hello,

 

I'm using the UPP driver for the C6748 located in \pspdrivers_01_30_01\packages\ti\pspiom\upp

 

I setup an SIO stream using the ISSUE/RECLAIM model and when I prime the input stream I need to include a Upp_transParam structure.  In this structure there is a member, bytesPerLine, a 16 bit unsigned int which limits the size of individual transfers to 65535 bytes.  Is there a way that I can exceed this transfer size?  

 

Thanks,

 

Scott

  • Hi Scott,

    The answer is NO.

    Explanation: 

    The value provided in the "bytesPerLines" will be written either into the UPID1 register or into the UPQD1 register depending on the channel selection (refer uppLoadPktToDma() in upp.c file). If you refer the UPP sprue register explanation (section 3.14 and 3.20), it explains that the only 16 bits are allocated for bytes per line field (byte count). This is the reason which made us to make the "bytesPerLines" as 16 bit unsigned int. 

    Thanks and Regards,

    Sandeep K

  • Yeah, that's what I figured but I was hoping you could explain to me how the BytesPerLine, lineCount, and lineOffset could be used to create even larger buffers.  In reading http://focus.ti.com/lit/ug/sprugj5b/sprugj5b.pdf section 2.4.1 it appears that the total length of the buffer is lineCount x BytesPerLine.  So defining the Upp_transParam like this:

    #define BUFSIZE 0x8000

    Upp_transParam  transParam;

    transParam.windowAddr = buf;

    transParam.bytesPerLine = BUFSIZE;

    transParam.lineCount = 1;

     transParam.lineOffset = 0;

    SIO_issue(uppInHandle, (Ptr)&transParam, BUFSIZE, NULL);

    would be equivalent to:

    Upp_transParam  transParam;

     

    transParam.windowAddr = buf;

    transParam.bytesPerLine = BUFSIZE/2;

    transParam.lineCount = 2;

     transParam.lineOffset = BUFSIZE/2;

    SIO_issue(uppInHandle, (Ptr)&transParam, BUFSIZE, NULL);

     

    and then by increasing BUFSIZE and line count I should be able to achieve larger and larger buffers.  

     

    Unfortunately, this is not the case.  It appears that memory is getting trashed when I increase lineCount.  What am I missing?

     

    Scott

  • Hi Scott,

    After glancing over the upp configurations, it looks like the BUFSIZE and buffer count is exceeding the available heap memory area.

    My suggestion here would be to conduct two experiments,

    1. Make sure that the driver works for multiple line counts, i.e keeping the BUFSIZE to 1024, increase the line count. It should work, i think you did conduct this experiment already. didn't you?

    2. Try to increase the BUFSIZE to 2K, 4K upto your requirement. On some point, you may hit the issue (as you have mentioned in the earlier post). Could you please share me the BUFSIZE and the line count at this moment?

    Above two experiment conclude that the driver works for the buffer size > 1024 and line count > 1.

    Basically, the heap memory will be allocated for an application by defining it in the tcf file. In the tcf file, there is an entry "heapSize" which defines the total allocated heap for the respective application. If the memory allocatted in the application exceeds this limit, there will be a problem. So, please cross verify the  "heapSize" and the (buffer size x buffer count). If this is the problem then, open the tcf file in any of the text editor and then change the "heapSize" according to your requirement.

    I hope this answered your question, let me know the result.

    Thanks and Regards,

    Sandeep K

  • Hi Sandeep,

     

    If I keep BUFSIZE less than 0x8000 then it appears to work.  Anything over and memory gets trashed, regardless of the number of lines.  My heap size is huge, 0x7C00000, and I dynamically allocate 3 buffers of size 20480000 16 bit words internally, or 0x7530000 bytes which should leave 0x6D0000 remaining.  

     

    Anyway, it seems to be working now so I'll carry on from here.

     

    Thanks for your help,

     

    Scott