TMS320C6657: UPP Stop/Start DMA Issue

Thanks Yordan, Here is more information:

I am configuring the UPP and it's DMA in the same manner every time. I have captured the UPP register values (below) for 3 consecutive runs.  In the first run, the UPP behaves as expected where I toggle a test point to show when the UPP DMA ISR is being serviced.  The period of the output waveform is as expected based on 40 lines at 32 bytes per line at around 4ms

The next iteration, even though I am configuring the DMA for 40 lines of 32 bytes per line (as in the first run), the window interrupt period doubles to around 8ms, This behavior continues until I cycle power, where we would see the first run as expected and double the window interrupt time period on subsequent runs.  

The image below indicates the settings being used for each consecutive iteration.  I capture the UPP register values after configuring, after I enable the UPP, and after I stop the UPP ( 3 sets of value per run). Please note I truncated the UPP prefix on the register labels...IE UPPIA is just IA.  

There are clues here (i'm assuming) in the status registers (IS0, IS1, IS2).  I'm just unsure of what to make of them right now.  I think I need to reset the DMA after each run to start with a clean slate for every UPP run, but I don't see any information regarding on how to do this.

Hi Eric,

It took me some time to capture data with a scope.  I had a bit of a code disaster this morning, and it took me most of the afternoon to recover.  I am now getting constant UPP behavior, but it's not what I would expect (or hope for) based on my settings.

I am using Single Data Rate.

I added some test code that enables the EOLI (end of line interrupt) for channel I.  In the ISR, I just toggle a test point when I get the EOLI interrupt.  That being said along with my code changes i see the follwoing:

1. First UPP Transfer
   1. EOLI occurs every 100 us, and it lines up with the "UPP_START" signal as epected.
   2. The EOLI occurs for 40 iterations, yielding a 4 ms window interrupt (window interrupt is also verified by toggling a test point in the ISR)
   3. I am able to observe/count the 40 EOLI interrupts in the window
   4. The entire data block is received succesfully (i'm using a test/count pattern, so this is easy to verify).
2. Second an dsubsequent UPP Transfers
   1. EOLI occurs every 200 us, because it is missing a "line."  I am able to view the EOLI toggling the test point, but it misses one of the UPP_START pulses

Here is my "artist" interpretation of the "missed" start pulse I"m seeing on the scope.  Please ignore any polarity issues, as this is just from memory right now.  The UPP interfaces really appears to be missing one fo these start pulses, and it's obvious.

The "missed" start pulse seems to be the root of the issue.  Is there any reason the UPP would be missing these?  

I would think the state machine would recognize the "UPP_START" signal and align the samples appropriately.  I am running the UPP in 16 bit mode, and I was able to verify there are 16 clocks in every window, which means 2 bytes per clock at 16 clocks for 32 byte line size  (which is what my UPP is configured for).  

Here is the method is use for controlling the UPP.  There are 3 basic functions

Configure:

1. Does a uppSwReset (leaving the UPP disabled via UPPCR enable bit)
2. Loads CTL, ICR, IVR, and TCR in that order (note the ICR is a 32 bit single access load per the peripheral's user guide)

Start:

1. Programs the DMA 
2. Enables the interrupts
3. Enables the UPP with the UPPCR register enable bit

Stop:

1. Disable Interrupts
2. Does a uppSwReset (leaving the UPP disabled via UPPCR enable bit)

I got a little carried away with the uppSwReset in hopes that this would resolve the situation, but I didn't have any luck.  I also captured the register values after these functions are run.  I am those results in the image below.  You will see groups of 3 register settings, where the first of each group is Configure, the second of each group is Start, and the 3rd of each group is Stop.

I have modified the source code a little bit, with no change in results. I switched to single channel, single data rate, and I'm still seeing missed lines.

This thread seems it indicate a continuous clock or pre and post clocking is required for the UPP state machine.
e2e.ti.com/.../426296

Is this accurate?

We have an OMAP-L138 that is hanging off of the same bus (logically the same  bust, however they are separate physical buses driven by the same source in an FPGA).  This OMAP does not have any any problems with reading the non-continuous samples.  The OMAP's peripheral information/register set looks like it's the same compared to the C6657.

Hi Mark,

All the documentation that I have on the UPP implementation in the C6657 indicates that the part expects a continuous clock. If you look at the description of the output clock you will see that it is a simple clock divider without any output control. The SoC designers may have taken advantage of this to pipeline the data as it enters the part. Have you tried the same test without reseting the UPP between transfers?

Regards,

Bill

Hi Bill,

I have some more information/details.  

I made the following changes.

1. Made the clock continuous (in our FPGA)
2. Enabled the use of the "ENABLE" line in the UPP Driver

I am still getting the same results. 

In all of the below plots

1. YELLOW = UPP_START
2. CYAN =  UPP_ENABLE
3. MAGENTA = UPP_CLOCK
4. GREEN = Test point that toggles for every End-Of-Line Interrupt

Here' is a capture that illustrates the "missed" START pulse:

Here is an Illustration of the setup and hold times for the Start and Enable signals.  

1. There is plenty of time allotted for each signal in each case.  
2. There is a slight discontinuity in the clock at the start/enable assertions but it seems like that shouldn't affect state machine.  There are a significant number of clocks prior to this. This discontinuity is a factor of the different "sample rates" not having a nice integer divide to get the data out of the UPP.  
3. The Start is High for 1 complete clock cycle
4. The Enable Signal is High for 16 clock pulses ( we are configuring the systems for 16 bit interface, 32 bytes per line, which  yields 32 bytes / 2 bytes (16 bits) per upp clock = 16 clocks.
5. Also of note, despite all of these UPP interface changes in our FPGA, the OMAP-L138 has been rock-solid in recognizing the samples properly.  It does not have an issue with missing the "start signal" and it does not use the "Enable" line in it's configuration.  
6. When I tried running without the enable line configured on the C6657, I get a bunch of 0's on the databus.
7. It's like the C6657 can't latch on to the start signal for a new  DMA line .  

Any idea what could be causing the UPP on the C6657 to be missing these end of line interrupts, even with all these changes?

I thought the "START" signal was supposed to indicate to the DMA controller it was supposed to start grabbing samples, but it doesn't appears to be working as I would expect. 

Some progress.

Previously the UPP bus was active (being driven by the FPGA) prior to configuring it in the C6657 software. I found that If I did not start the bus (driven by the FPGA) until the UPP was configured and waiting for samples (DMA programmed, interrupts enabled), that I was not missing those start pulses.

I feel like the C6657 is extremely picky about how the UPP runs. The OMAP-L138 did not have a single issues, as I progressed through the stages of debug (no extra clocks, to extra clocks, to continuous clock).

Update:

The same condition happened again after a bunch of run time.  It seems like it could be this start condition.  I'm going to continue to dig.  

Hi Bill,

I have 4 tasks

2 are parsing serial data (low overhead kind of stuff, and low Sysbios Priority = 5)

1 processing the samples mid priority  (Sysbios priority = 10)

1 handling the UPP (getting samples from the DMA buffers, and initializing the next UPP transfer after the EOWI).  This is the highest priorty task (SysBios priority = 15)

    the UPP ISR is just posting events to this task. It does not do any "heavy lifting" at all.

The one thing I am doing, but I"m not sure if it's "acceptable" is programming the UPP while it does not have it's clock being driven.  

I configure all of the UPP registers, as well as the interrupts, and DMA, and then roughly 35 to 40 ms later, the UPP bus starts with Enable and Start Lines Driving first, followed by the clock signal (to satisfy the setup/hold time).  The transfers continue as you saw in the previous plots.  

Hi Bill,

I did one more experiement because I'm trying to align the window interrupts between the OMAP part and the C6657.  The C6657 Window initial interrupt (signified by toggling a test point) wanders around, when compared to the OMAP.  The OMAP always seems to have it's first Window captured consistently every time I run.  To troubleshoot this, I enabled the EOLI (END-OF-LINE I Interrupt), and captured the DMA status registers the first time it occurs on a transfer.

After 4 capture sessions, i saw the following status register settings (after the first EOLI)
Note: I split the UPPIS1 register into the high and low 16 bits representing line count and bytecount

I would expect to see a line count of 1 or 2.  It seems like there are "stale" transfers in progress (maybe from the last time the transfer was stopped).  

1. Shouldn't the uppSwReset clear out these old statuses (reset the linecount)?
2. Is there any info I can gain from the UPIS2 as to why there seems to be some pre-existing lines already "transferred"?