• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 739 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

OMAPL138 UPP Receiver

Ben Campbell
Prodigy 70 points

Other Parts Discussed in Thread: OMAPL138

6523.upp_test.zip

Hello,

Please can you help me to get a simple UPP receiver working on the OMAPL138? I am using the Avnet OMAP/Spartan6 platform. I am using dsp/bios 5.41.03.17, code gen tools 6.1.9, ccs4, pspdrivers 01.30.01. I can get the pspdriver UPP loopback example to work correctly on my platform but I cannot get my FPGA to OMAP UPP receiver to work. I have attached my project.

I have the FPGA set up on the platform so that when I press a button the FPGA sends a UPP 'packet' to the OMAP. A logic analyser screen shot is shown below. D0 is UPPclk (FPGA->OMAP), D1 is UPPstart(FPGA->OMAP), D2 is UPPen(FPGA->OMAP), D3 is UPPwait (OMAP -> FPGA), D[7..4] is UPP[0..3] (FPGA -> OMAP). So you can see the FPGA enables and starts the packet, then sends 0,0,1,0,2,0,3,0,4,0...31,0 (so 128 bytes in total (the data bus is 16 bits wide)).  Note that the OMAP->FPGA UPPwait is asserted all the time.

As assume I must not be setting up the UPP port in software correctly, but I cannot work out what the problem is. In my software, I am using CCS to debug the project using the on-board XDS100v2 emulator. I see all the LOG_printf statements up until "created upp handle\n". The GIO_read function never returns. Please could you take a look and let me know the error(s).

Many thanks for your help,

Ben

  • 0
    TI__Expert 8890 points

    Ben,

    The only thing that stands out as "bad" in your signal capture is that the WAIT signal should not be asserted.  In normal operation, the uPP peripheral should never assert WAIT unless it is held in reset.  The fact that WAIT is asserted in your system may mean that the peripheral is not configured correctly or that the pinmux is not set correctly.  Here is some alternative pinmux code if you want to double check that possibility:

    // 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;
    }

    You may also want to halt execution after applying the pinmux settings so you can check the contents of pinmux registers 13-18.

    I also want to make sure I understand the sequence of events.  Here's what I think is happening based on your e-mail:

    1. DSP application begins to run
    2. DSP application calls GIO_create()
    3. DSP application calls GIO_read() to wait for an incoming 128-byte transmission
    4. FPGA sends 128 bytes of data to DSP (as seen in screenshot)
    5. DSP does not return from GIO_read()

    The order of steps 3 and 4 is important, so please let me know if I've misunderstood any part of the procedure.

  • 0 in reply to Joe Coombs
    Prodigy 70 points

    Hello Joe,

    Thank you for your quick response.

    I have replaced the pin mux setting code with your alternative and I find the registers are set correctly. I checked with the original code and they are set the same. But the wait signal is still asserted.

    Copied from the register view:

    PINMUX13 = 0x44440800
    PINMUX14 = 0x44444400
    PINMUX15 = 0x44444444
    PINMUX16 = 0x44444444
    PINMUX17 = 0x44444444
    PINMUX18 = 0x00444444

    Your event sequence is exactly correct. The 128 bytes are transmitted as 64 rising clock edges x 16bits.

    Ben

  • 0 in reply to Ben Campbell
    Prodigy 70 points

    Hello Joe,

    I have realised my mistake. The Avnet board schematic labels the UPP channels 0 and 1. These are not mapped to channels A and B as I assumed (0->A, 1->B). They are mapped the other way around (0->B, 1->A). Having swapped the signals in my FPGA I get a clear wait and a successful return from GIO_read. Sorry to have wasted your time.

    Best wishes,

    Ben

  • 0 in reply to Ben Campbell
    TI__Expert 8890 points

    Ben,

    Glad to hear that your uPP transfers are working.  You're correct that some documents still refer to uPP Channels A and B as 1 and 0 (respectively).  Sorry for the confusion.