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.

OMAP-L138 uPP DSP/BIOS driver v10 problem in transmit mode

Other Parts Discussed in Thread: OMAP-L138, OMAPL138

Hi there,

 

I'm currently working with the OMAP-L138 Kit from LogicPD and try to run the uPP.

I want to use the example upp_DSP/BIOS_driver code from the davincidsp wiki-page. I just changed into transmit mode and tried to capture the data.

But when I run the program the upp_interrupt_cout is never increased, and thus it gets stuck in line 206.

I get also 2 Errors when I start CCS3.3 because it can't find the 2 GEL files OMAPL138_DSP.gel and OMAPL138_ARM.gel. But I think it should be negligible, as it says that the initialisation doesn't rely on GEL.

Is there an update for this example code? Or anyone had encoutered this problem as well?

It is my first programming project, so a working example would help me a lot! Thanks!

 

Best Regards,

Michael

 

 

  • Michael,

    Are you using the "test" application that comes with the uPP driver?  If so, I would encourage you to try out the digital loopback (dlb) mode first with all of the default settings.  Then, if that test passes, you can try changing settings and running in different modes.

    Also, what are you using to capture the transmitted data?  If an external device holds one or more of the uPP control pins high or low, that can prevent the peripheral from running.  If you're still having trouble, you should try running the test case with nothing connected to the uPP pins.  You'll also want to double check the switch settings on your board to make sure the uPP signals are being routed correctly.

    Finally, be aware that Logic PD's schematics have some errors regarding uPP pin names.  They label the Channel A control pins as "CH1" and the Channel B control pins as "CH0".  They also label the uPP DATA pins as CH1_DATA, which is not always correct.  (See the uPP user guide on ti.com for information on the difference between DATA and XDATA pins.)

    Hope this helps.

  • Joe,

    thanks for your quick response!

     

    Yes I'm using the "upp_drv_test" application. I just ran the DLB mode this moring and it worked fine. Then I changed the mode to transmit and it got stuck at the same line of the code. Nothing was connected to the connector of the uPP at this time though.

    To capture the data I just used an oscilloscope and single trigger on rising edge, just to see if I can get anything. For this reason we did a little passive adapter PCB. It routes the pins of the connecter to a pin header just to ease measurements.

    Later a colleague helped me to check the setup and sample program, as he is more experienced in DSP programming than me. We tried a lot to swap the modes and check the registers, because in both cases CH A is in transmit mode. After a while we finally got the transmit mode to work. Then we swapped back to DLB and back to transmit, just to see if it is still working. But it didn't. Seems to be that it works sometimes, but we couldn't figure out the reason, even after checking the regs and stepping through the program.

    I guess as it was working once, we have the right DATA pins and register settings, we just have no idea what else we could do.

    I also loaded the correct GEL files, to make sure that this doesn't create the problem.

    We are working with CCS v3.3 on a WinXP machine if that might help.

     

    Cheers,

    Michael

  • Michael,

    If it's working intermittently, your problem is probably on the hardware side.  Here are some possible "gotchas" to watch out for:

    • Check the DIP switch settings on your board.  There's at least one DIP switch that needs to be set to ensure that all of the uPP signals reach the connector on the base board.
    • Check what (if anything) is connected to the WAIT pin for channel A.  WAIT must be held low in transmit mode.  If it floats, the channel may unpredictably stall out or fail to start.  If it's not connected to anything now, you should try connecting it directly to ground.
    • Make sure that nothing else is driving (or shorting) the channel A START, ENABLE, and CLOCK signals.  The uPP peripheral must be able to drive these signals in transmit mode

    (As a reminder, the channel A control pins are labeled as CH1 in LogicPD's schematic, as in UPP_CH1_WAIT.)

  • Joe,

    the problem was definately the floating WAIT pin. Just connected it to ground on my little adapter baord and finally the transfer always works fine!

    Thank you for your help!

    Michael