RTFS UPP conflict

Hi Ace Sorensen,

Ace Sorensen said:

When I use RTFS and Upp together operating in different threads, in cases of large data transfers and saves Upp returns a general -1 error IOM_EBADIO and even if I do GIO_delete and try to reconfigure it, it fails (that time with -6, or IOM_EABORT).

Can you provide some more details on this?  What function is returning "a general -1 error"?

Ace Sorensen said:

I'm suspicious that both the Upp GIO driver and RTFS are using EDMA and possibly stomping each others PINMUX or something like that but I haven't been able to track it down.

We have seen conflicts occur when combining different components.  See the answer in the following thread for more on this.  Can you check the h/w interrupt assignments between UPP and EDMA/RTFS for overlap?

http://e2e.ti.com/support/embedded/bios/f/355/t/112802.aspx

Steve

Thanks for taking a look! The callbacks for GIO_submit receive a status of -1 from the UPP interrupt.  They're simple:

Void uppTxCb(Ptr arg, Int status, Ptr bufp, size_t sz){
    if(IOM_COMPLETED != status){
        rxStatus = status;
        SEM_postBinary(failSem);
    }
}

Void uppRxCb(Ptr arg, Int status, Ptr bufp, size_t sz){
    if(IOM_COMPLETED == status){// || IOM_TIMEOUT == status){
        SEM_postBinary(rxSem);
    }else{
        txStatus = status;
        SEM_postBinary(failSem);
    }
}

That link you shared was part of why I was suspicious but I haven't been able to figure it out.  I have, however, discovered some more *hopefully* useful information:

UPP register UPISR is reporting an underrun or overflow.  

• UORQ is true indicating DMA Channel Q Underrun/Overflow
• UORI  is true indicating DMA Channel I Underrun/Overflow.  
• Register UPIER also reports channel Q's status in UORQ as true.

From further testing it appears that if the UPP interrupts the RTFS, I get the error.  But if RTFS interrupts the UPP Tx or Rx I don't.  Any idea why that would happen?

Ace Sorensen,

Please validate your work setup for UPP with RTFS.
Will you test the UPP application alone and MMC/SD using RTFS seperately?
You can find the UPP test code using BIOS at the below wiki page,
http://processors.wiki.ti.com/index.php/Using_the_uPP_DSP/BIOS_Driver

Please have a look at the configuration file(tcf) for hardware interrupts(HWI) for UPP and MMC/SD application.

I created my test project by first verifying the MMCSD example worked.  It was the rtfs_1_10_02_32\packages\ti\rtfs\examples\mmcsd\bios5\evm6748\ccs4 project.  Once that was finished I created a UPP project that also worked separately and verified it by running loopback data transfers.

After I verified both worked independently I merged them (tcf file and all).  I don't see the error if the RTFS has higher priority (I've run it a few thousand times that way), but it is failing to even open the file for writing.  UPP on the other hand locks up with the above mentioned error when transfers are higher priority (error occurs at first or second RTFS write).

Ace Sorensen,

Can you provide your merged project (source code) to look and give the technical suggestion.

Are you using same gel file for all the three different projects(UPP, RTFS and UPP with RTFS)?

The MMCSD (used by RTFS) and the UPP driver (used by UPP) both are using HWI7 (Refer the upp_drv_test.tcf and mmcsdSample.tci). This may be causing your program not to work.

And also verify the memory section at linker file (.cmd)

I've tried to move the dependency on HWI7 but I'm not sure I did that right - how would you go about that?  Also I use the same gel for all three, and can I get your email or something to send you the project?  I'd prefer not to attach it here if possible.

Ace Sorensen,

Thanks for your update. Please share your code: pubesh.r@ti.com

Ace Sorensen,

Find the attached bios5.zip, which is combined project for MMC/SD and UPP.
Please rename or remove your bios5 folder mentioned at the below path,
rtfs_1_10_02_32\packages\ti\rtfs\examples\mmcsd
Right now I do not have the hardware setup to test on the same.
I believe that, this code may help you. If possible update the status after test this code on your end.

8814.bios5.zip