Bf548 - LCD and AD1980 noise


We're developing an application that uses both the LCD screen and the AD1980 codec and I'm having small compatibility problems that need to be fixed.

Using the Audio Loopback example coupled with the RGB_Out we have developed an application that displays the audio data on the LCD screen in either the time or frequency domains.

The problem is that there is considerable noise in the audio buffer, the music is somewhat audible but there is noise and almost a phaser and bit-crushing effect happening to the sound, when bass occurs the noise amplitude seems to be higher.
This noise stops when the LCD screen is disabled.

First I through perhaps it could be memory allocations, but I experimented putting the audio data in various areas of memory and the problem persists.

I have briefly looked at DMA priority and rearranged the DMA priority of SPORT0 (Audio) and EPPI0(LCD) in so that the audio interrupt has priority over the LCD, but this didnt seem to have any affect.

The LCD doesn't uses Loopback and not deferred callback.

I have tested this now on multiple Blackfins.

Any suggestions, am I missing something?

  • 0
    •  Analog Employees 
    on Oct 4, 2012 7:20 PM over 8 years ago

    Without knowing the very specific details of the application, there could be many things going on that are contributing to your problems.  You seem to have tried to focus on the system bandwidth from a data perspective, but the fact that giving the SPORT priority over the PPI didn't seem to help suggests you may have an external memory access problem between data movement and code execution.  If you did not modify the audio loopback example, then this simply DMAs audio in from the SPORT from the ADC, copies the buffer to a destination buffer, then DMAs the original data back out to the DAC to your speaker.  The RGB_out has two ping-pong buffers that you must also be populating, which raises a couple of questions:

    1> You must be doing some sort of processing of the same audio stream in order to properly initialize and output the ping-pong buffers to the LCD.  How is this being done?  Where is this code located?

    2> What are the clock rates for the PPI and SPORT?

    3> Where are all the buffers located (PPI ping and pong, and SPORT source and destination)?  You mentioned troubleshooting the issue by moving the buffers around in memory, but you didn't indicate whether this was experimentation with various external banks of DDR memory or placement of buffers in on-chip L1/L2.

    4> When you say you "disable the LCD", do you mean that the PPI port is disabled, but all the other processing for your application still runs as normal?  Or does this also remove all the PPI processing code as well?

    5> When you change the DMA priority to favor the SPORT, do you also give the SPORT interrupt higher priority than the PPI interrupt? (this may not matter, depending on your answer to #1 above)

    While DMA arbitration certainly plays a role in your system bandwidth (specifically over the DDR), there is also the core vs DMA priority to consider.  If the core needs to make repeated external accesses to parse these data buffers and process them, then you could be bottle-necking the DMA accesses on the whole, but it could be the case that eliminating the PPI DMA gives you enough bandwidth to still get away with it.  Even if the code that does all the processing is in L1 or L2 memory, the data accesses could still be to the DDR space and conflicting with the various ongoing DMAs...but if the code itself is ALSO out in DDR space, then you're also introducing core accesses for external instruction fetches, thus further consuming bandwidth.