Basic DLB Loopback example without using driver

Bruce Weyrauch

Other Parts Discussed in Thread: SYSBIOS

I am having trouble getting the simple DLB example in the uPP guide to work for me. The code is part of a SYSBIOS project, so I have not been able to use the DSP/BIOS v5.xx driver. Here is the test code I am using:

....... extraction from working SYSBIOS DSP application.......

      case RCMD_UPP_TEST_RCVR: // 0xD4 -- DLB test
         UPP_DLB_B_A_Init();
         UPP_DLB_B_A_Start();
         WaitMsec(20); // Wait for end of 256K transfer -- should take around 2.5 msec? Sysclk is 299 MHz
         if((UPP->UPISR & 0x00000008L) == 0)
         {
            m_SEND_NAK(DSP_EX_UPP_TIMEOUT);
         }
         else
         {
            m_SEND_ACK;
         }
         break;

void UPP_DLB_B_A_Init(void)
{
   int i;

   for(i=0; i<0x20000; i++)
   {
      UppRcvBuffer[i] = 0;
      UppDlbSendBuffer[i] = i;
   }
   //reset uPP
   SETBIT(UPP->UPPCR, UPP_UPPCR_SWRST);
   for(i = 0; i < 300; i++){};            //wait 200 clock cycles for reset.
   CLRBIT(UPP->UPPCR, UPP_UPPCR_SWRST);

   //setup control registers
   UPP->UPCTL=0x52020006;
   UPP->UPICR=0x01000000; // CLKDIVB = 1
   UPP->UPIVR=0x0BBB0000;
   UPP->UPDLB=0x00002000;
   UPP->UPPCR=0x00000008L;
}

void UPP_DLB_B_A_Start(void)
{
   //setup DMA-I registers
   UPP->UPID0= (uint32_t)&UppRcvBuffer[0];
   UPP->UPID1=0x04000100; // Line count(1024) and Bytes per line(256) (Transfer size = LineCount*BytesPerLine = 256K)
   UPP->UPQD0= (uint32_t)&UppDlbSendBuffer[0];
   UPP->UPQD1=0x04000100; // Line count(1024) and Bytes per line(256) (Transfer size = LineCount*BytesPerLine = 256K)

}

When I run the test command, the uPP resgisters show that is is enabled, but no DMA transfers occur. I checked that the clock is active and the module is in the enabled state. What am I missing?

over 14 years ago

0 Joe Coombs over 14 years ago

TI__Expert 8890 points

Bruce,

Did you setup the uPP pinmuxing? This is required even for DLB applications. Here's some simplified pinmux code you can try:

// kick and pinmux registers (lifted from GEL)
#define SYS_BASE        0x01C14000
#define KICK0R          *(unsigned int*)(SYS_BASE + 0x038)
#define KICK1R          *(unsigned int*)(SYS_BASE + 0x03C)
#define PINMUX13        *(unsigned int*)(SYS_BASE + 0x154)
#define PINMUX14        *(unsigned int*)(SYS_BASE + 0x158)
#define PINMUX15        *(unsigned int*)(SYS_BASE + 0x15C)
#define PINMUX16        *(unsigned int*)(SYS_BASE + 0x160)
#define PINMUX17        *(unsigned int*)(SYS_BASE + 0x164)
#define PINMUX18        *(unsigned int*)(SYS_BASE + 0x168)

static void LOCAL_apply_upp_pinmux()
{
    // enables register access at run time
    KICK0R = 0x83e70b13; // Kick0 register + data (unlock)
    KICK1R = 0x95a4f1e0; // Kick1 register + data (unlock)

    // all pins (channel A, channel B, DATA, and XDATA)
    PINMUX13 = (PINMUX13 & 0x0000FFFF) | 0x44440000;
    PINMUX14 = (PINMUX14 & 0x000000FF) | 0x44444400;
    PINMUX15 = (PINMUX15 & 0x00000000) | 0x44444444;
    PINMUX16 = (PINMUX16 & 0x00000000) | 0x44444444;
    PINMUX17 = (PINMUX17 & 0x00000000) | 0x44444444;
    PINMUX18 = (PINMUX18 & 0xFF000000) | 0x00444444;
}

Let me know if this helps.

0 Bruce Weyrauch over 14 years ago in reply to Joe Coombs

Intellectual 535 points

Joe,

I think my PinMux is set up OK for our hardware configuration. Here are the values I am using.

#define PINMUX13_VALUE 0x44448818   // UPP_CH1_WAIT, UPP_CH1_ENABLE, UPP_CH1_START, UPP_CH1_CLK, GP6[12],GP6[13],OBSCLK0, GP6[15]
#define PINMUX14_VALUE 0x88888880   // RMII_RXER, RMII_RXD[0], RMII_RXD[1], RMII_TXEN, RMII_TXD[0], RMII_TXD[1], GP6[6], UPP_2xTXCLK
#define PINMUX15_VALUE 0x44444488   // UPP_D2-UPP_D7, RMII_CRS_DV, RMII_MHZ_50_CLK
#define PINMUX16_VALUE 0x88888844   // GP7[10]-GP7[15], UPP_D0, UPP_D1
#define PINMUX17_VALUE 0x44444488   // UPP_XD2-UPP_XD7, GP7[8], GP7[9]
#define PINMUX18_VALUE 0x11822244   // MMSCSD1_DAT[6],MMSCSD1_DAT[7], GP8[12], MMCSD1_CMD, MMCSD1_CLK, MMCSD1_DAT[0], UPP_XD0, UPP_XD1

The design plan for our custom board is to perform 16-bit transfers from an FPGA using Ch A in 16-bit receive mode. Our hardware interface only uses pins UPP_D0 -UPP_D7, and UPP_XD0 - UPP_XD7, along with the CH_A control signals for receive. The other UPP pins are used for things like RMII for ethernet, etc.

I thought I would get started by getting a simple DLB working before I tackled our custom hardware. I do notice differences where your PinMux sets up some of the other pins our hardware does not use. Maybe something here could be the issue?

Bruce

0 Joe Coombs over 14 years ago in reply to Bruce Weyrauch

TI__Expert 8890 points

Bruce,

Unfortunately, the uPP peripheral does not use DATA[7:0] and XDATA[7:0] in a one-channel configuration. Instead, it will use DATA[15:0]. Take a look at Table 3 in the uPP user's guide; it shows how the DATA and XDATA pins are assigned for various configurations.

Due to pinmuxing conflicts, it will be difficult to use uPP in 16-bit mode while also using EMAC RMII. One possibility may be to use the following configuration:

2-Channel mode (UPCTL.CHN = 1)
Channel A receive, 16-bit
Channel B (don't care), (don't care)-bit

This may work as long as you don't attempt to use uPP channel B. If possible, I would recommend limiting yourself either to 8-bit uPP receive or to only using EMAC MII (which does not conflict with uPP).

Regardless, I don't think that you will be able to run a uPP DLB test using the pinmux you listed in your post. To run a DLB transfer using both uPP channels, you will need to enable the full uPP pinmux.

Hope this helps.

0 Bruce Weyrauch over 14 years ago in reply to Joe Coombs

Intellectual 535 points

Joe,

Thanks for your quick feedback.

I understand now why the DLB won't work. I will probably try disabling the RMII for awhile to test a DLB example, but in the end our board has to use RMII since a number of the MII pins are needed for UART interfacing.

Continuing on the 16-bit CH_A receive transfer plan, I agree that the only possible mode given our hardware configuration is the 2nd to last line in Table 3. That was going to be my attempt. I had no plans to activate channel B, so I'm hoping I can get it to work. Our overall data transfer rate from the FPGA is 102.4 MiBytes per second, so an 8 bit solution won't work either, since that exceeds the maximum clock rate of 75 MHz.

I'll experiment a little more and get back to you.

Processors

Processors forum

Basic DLB Loopback example without using driver