• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 102 subscribers
  • Views 1843 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 sustained transfer errors

Bevis Peters
Prodigy 110 points
Other Parts Discussed in Thread: OMAP-L138

We are attempting to do sustained writes from the ARM out to an FPGA via uPP.

We are running the UPP device in a two channel 16 bit mode, with an 8192 line count and the system priorities set for uPP = 0.  Our code is set to create a large block of data, tell the UPP to start transmitting it, wait for UPP to complete, then immediately repeat with another large block.

We find that we always miss data at some point when doing this, for any size of data block from 32kB to 7MB, even if we slow the clock down considerably from its maximum 66MHz to 7MHz.

The issue appears to be memory contention on the ARM - at some point the Linux OS we're running on there will be loaded to the point where the UPP misses a data block.  We can work around this by blocking the OS completely while the transfer is in progress (by disabling all linux interrupts), but that is not ideal.

We believe that if the UPP is unable to get data from the DMA due to any reason, it should deassert the ENABLE line until it can again, but we never see that.  Is there any known problem with the UPP design?

We also often see a miss in the data without ever seeing the underrun/overflow interrupt raised - without this indication, there is no way to know that the data transfer has not been successful, which makes the UPP unusable.  Is there a genuine situation in which this could occur?

  • 0
    TI__Guru** 116100 points
    Hi Bevis,
    Are you using any buffers for uPP operation in your code ?
    If yes, whether it is in DDR or any other RAM ?
  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 110 points
    We're placing the data in a chunk of contiguous memory on the board (we're using an OMAP-L138 SOM-M1) which is 166 MHz Mobile DDR SDRAM.
    We then pass the base address & size on to the UPP.
  • 0 in reply to Bevis Peters
    TI__Guru** 116100 points
    Could you please try to use internal shared RAM (L3) instead of mDDR.
  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 110 points
    We did try this, but found that the UPP was unable to see the shared RAM. The data sheet stated that this RAM was only available to some peripherals; we assumed that UPP was not one of these.

    Nevertheless, it wouldn't really solve the problem since there is only 128k or RAM available there, which is rather small for the large transfers we would like to do, and wouldn't help with the ENABLE pin issues we see, and missing interrupts.
  • 0 in reply to Bevis Peters
    Prodigy 110 points

    Any chance of getting more input on this?

    It seems too remarkable that the UPP would have been designed so that if there is memory contention it skips data rather than waiting to regain access, and that it would not report this happening.

    Have you managed to run large (MB) data transmits from the ARM out successfully on a loaded processor?

  • 0 in reply to Bevis Peters
    TI__Guru* 78305 points
    Hi Bevis
    No concrete suggestions, as I don't have hands on debug experience with uPP. Reading through the TRM, I am not sure enable signal will toggle in your scenario, it is also unclear whether or not underflow/overflow should truly get set - are you sure there is nothing wrong "on the wire" or your receiving logic in FPGA?

    It is a good data point that reducing the clock rate did not help, but changing the ARM traffic does help - could there be some resource contention issue in software more than just a data bandwidth contention?

    What is the OS activity , do you expect that just to be contending for DDR bandwidth in conjunction with the UPP payload on DDR?
    Can you cross check that the DDR PBBPR register PR_OLD_COUNT is set to something lower than default of 0xff, usually a good value to start with is 0x20.

    Titus's suggestion on trying SHRAM is also good as a debug step, understood that it may not be a long term solution for you , given the limited size of SHRAM. FYI, there is no issue in terms of UPP being able to access this chunk of memory, if it is not working in your setup, perhaps there is some software/config issue.

    Regards
    Mukul
  • 0 in reply to Mukul Bhatnagar
    Prodigy 110 points

    Thanks for the reply!

    I revisited the L3 shared memory option, and did indeed get that to work, and it does so without showing any of the data corruption that we have with the DRAM.  We find that splitting our data into 128kB chunks and sending those out via the L3 ram does give us just enough bandwidth, so we do have a work around solution, but it would be good to understand why using DRAM dos not work.

    When reading data from the FPGA to the ARM via UPP, we get no corruption at all, it's only writing data out.  Given that the clock speed makes little difference, but completely blocking the kernel by disabling all interrupts while running the transfer does, we believe it to be a ram contention issue rather than a ram bandwidth problem.

    I'm currently trying to check the PR_OLD_COUNT value.

  • 0 in reply to Bevis Peters
    Prodigy 110 points
    We have also now tried setting the PR_OLD_COUNT value from 0xFF (the default) to 0x20 (as recommended in the data sheet), and this does actually fix the original data corruption problem. It's a little irritating that 0xFF is set as the default, and not 0x20 or similar!
  • 0 in reply to Bevis Peters
    TI__Guru* 78305 points

    Hi Bevis

    Good to know. 

    What software base are you using? My recollection is that in uboot etc and possibly gel files ,we do change this value from default to lower. It is indeed a bad default in hardware/IP, but we do try to highlight to customers to change this. It is a system tuning knob, so not necessarily one shoe fit all value. 

    Some concepts on this on the processor wiki too

    Hope this helps

    Regards

    Mukul 

  • 0 in reply to Mukul Bhatnagar
    Prodigy 110 points
    We originally took the software that was shipped with our L138 dev kit, I'm not certain of the version that is, but it has been quite heavily modified, so possibly if originally there was a better value set, that seems to have been lost - I could believe that.
  • 0 in reply to Bevis Peters
    Prodigy 40 points
    We are facing a similar issue. uPP on OMAP-L138 is giving under run error when ARM CPU clock is increased from 300MHz to 444MHz. We have tried all that has been suggested in this thread but there is no improvement.


    Thanks in Advance
    Guru
  • 0 in reply to Guru Shankar
    Prodigy 110 points

    Have you tried using the L3 ram on board the ARM itself?  That did fix everything completely for us.

    Changing the PR_OLD_COUNT value to 0x20 did also work, though we could envisage that still failing if there was enough RAM contention.