uPP driver

Hi,

There is CSL support for the UPP interface, but we do not have plans for an LLD.  We can probably supply example code/project that uses the UPP CSL if you are interested.

Regards,

Travis

Hi Travis,

Thanks for your replay and please send me the example code to dpinglee@163.com 

My opinion: since uPP could be used an successor of HPI and VPort. It's necessary to support uPP mini-driver withing edma.

Regards,

dp 

Thanks Varada,

I'll test as soon as I get the evm6657.

Regards,

dp 

Varada,

I am trying to run your example code on the C6657EVM and having some problems that I was hoping you might shed some light on.

1) When I read the UPP PID I get 0x44231100 rather than the 0x44230100 defined in the CSL

2) When the check for error condition occurs after the transfer is initiated/completed I get a UPISR value of 0x00003c3c indicating an internal bus error condition.

I am using the following :

MCSDK 2.1.0.3

MCSDK PDK C6657 1.1.0.3

Jim,

1) What you read as the UPP PID is the correct value. CSL needs to be corrected. Future release will have the fix.

2) About error you are getting , can you ensure that "upp_pinmux_enable" is executed ? This function is needed even if you are in the internal (digital) loopback mode.

Let us know.

Varada,

Thank you.  As far as the bus error, I moved the buffers from L2 memory to MCSM and the problem went away. I had put them in L2 as your example indicated.

I am new to this processor, so perhaps there is some configuration I need to do to use the L2 memory for this purpose?

Thanks for the update. About the configuration for using L2, I will consult the device expert and revise.

One possible cause of this error : 

In your setup, Is the L2 memory in which DMA buffers are located, configured as cache ? Refer “L2CFG“ register of the device.

Varada,

A quick follow up question, I see that in your upp_key_config function, you disable the L1D cache.  Is this for some reason needed for using the UPP?  It has a significant negative impact on the performance of my code.

Thanks for your help.

OK, with the buffers in L2SRAM and the L1D cache enabled, the received upp data is not written to memory.  It works if I put the buffers in MCSMSRAM.  Any insights would be appreciated.

Thanks

Dear Jim && Varada,

Would  you like to upload a modified version of "2350.upp_dlb_test.zip" on the page? I am studying uPP these days, but meet with many troubles

Regards

Yuanrui

OK, I solved the problem.

First, the CSL haven't fix the bug.

Second, the linker.cmd file use DDR3, but I need to init DDR3 first.

Hi

Sorry that joining a bit late this thread, but I would like to know if it was clarified why you need to disable the L1D cache and place the xmit and rcv buffers in  MSMCSRAM ?  

regards

Iso 

There shouldn't be a need to disable L1D cache, but by default the MSMC memory is cached in L1, so if the example provided doesn't incorporate the needed write-back, invalidate cache functions, it would fail.  There are plenty of threads on MSMC, MPAX, cache if you search.  On the one below, I noted that you could remap MSMC memory to a non-cachable range using MPAX, this would allow you to leave L1D cache enabled. 

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/309132/1078556.aspx#1078556

Regards,

Travis

Hi 

Thanks for the reply.

However my concern is not so much about the cache issue. I just asked about this, because I noticed that the L1D cache was diabled in the original upp example.

But my main problem is that the upp loop-back function that I am testing doesn't work when I map the xmit and the rcv buffers to L2SRAM. They both have to be mapped to either MSMCSRAM or DDR3. I have tried to disable the L2 cache, but that doesn't change anything. Data is not transferred from the xmit buffer unless both buffers are in MSMC or DDR3

Izydor

So with L1D cache disabled (like the original upp ex), you can't get your example to work with rcv and xmit buffers in L2?  If L1D cache is enabled, it will act the same way I described above with MSMC memory, unless you turn off the cachability of L2 with the MAR bits for the region of memory in L2 that holds your rcv and xmit buffers.  Also, how are you addressing the buffers, i.e. global or local addresses.  Anything other than the CPU must use global.  Not sure if that is helpful, but it is all I can think of at this point.

Regards,

Travis

Yes - when I use exactly the same code (with or without cache enabled), and place one of the two buffers (or both) in L2SRAM, then it doesn't work. The transission from xmit to rcv buffer diesn't happen and I get the ERRI and the ERRQ error conditions in the  UPISR register. Could this somehow be related to the EVM board, I am using ?

regards

Izydor

I doubt it is EVM related.  How are you disabling L1D cache, or are you disabling the cachability of L2 with the MAR bits?

I am been trying to disable both the L1 and the L2 cache with the L1DCFG and the L2DCFG registers as well as using the cache Gel functions, but with no effect on the problem. 

Ideally I would like to run my whole prgram from L2SRAM and therefore to have both the rcv and the xmt buffers there. In the end, the idea is to connect to an external  DAC via the upp , but I see the loop-back exersize as a step to gain understanding of how the upp works and should be used.

Izydor  

Hi again

Ok - I found a solution.  I cannot explain why it works , but it does work. The solution is the following:

In my previous linker file, the memory section where I declare the L2SRAM looked like this:

L2SRAM (RWX) : org = 0x0800000, len = 0x000FFFFF

When I change that part to:

L2SRAM (RWX) : org = 0x10800000, len = 0x000FFFFF

then it works with both rcv and xmt buffers mapped to the L2SRAM. Can you explain why ? I thought those two ways would be equivalent.

Regards Izydor

Izydor,

Using the local address in the linker cmd file is allowable, this essentially allows every core of the device to use the same section of L2SRAM in its respecitve L2 memory.  So I'm not sure what exactly is going on, but it seems to point to the example code not using the correct addresses when accessing this space.  As I mentioned above, only the local cpu can use the local address, any other master, i.e. edma, peripheral, or non-local cpu must use the global address.  Can you verify this is happening?  You will have to do a local to global conversion of the address for these accesses from other masters.

Regards,

Travis

Hi again

Yes I have been working implementing quite a lot of other stuff using the local adress for L2SRAM, but always staying within the same core. But now, after reading the C6657 user guide, I understand that it make sense to use the global adress for the L2SRAM when using the UPP since this is a peripheral outside the core. So I think the problem is solved now with this change. I don't observe any difference for the rest of the code using global adress for the L2SRAM.

Just one additional question: I intend to use the UPP with external clock since I need a clock frequency for the DAC which has cannot be generated by the internal clock. But isn't is so that the socalled module clock for the UPP is just an internal clock which is "invisible" from the outside. I jus need to apply the transmit clock - right ? 

regards

Izydor

I'll need to have others answer this one.  Let me forward internally.

Thanks,

Travis

Please refer to section 2.1 in the UPP UG (SPRUHG9).  The RX clock can be provided directly.  The TX clock must also be provided that is synchronous and 2x the required rate.  Then the device will drive out the TX data with the associated TX clock.

Tom