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.

C5515 ezDSP - An audio i/o example using CSL exclusively (interrupt problem?)

Hello all,

having read various posts around this forum requesting support for several issues I have seen that TI employees suggest using the CSL for simplicity and better support.

So I am using CSL 3.01 and CCS 4.1.3 and a C5515 ezDSP board to program an audio/input output example.

I am doing the following:

1. Use CSL_PLL to initialize the PLL to 100MHz

2. Use CSL_INTC to setup the DMA ISR and enable DMA interrupts

3. Use CSL_DMA to configure DMA0 CH0-3 in ping pong mode

4. Use CSL_I2S to configure I2S

5. Use CSL_I2C to setup comminication with AIC3204 and setup AIC3204 according to other examples.

6. I have an infinite while loop that keeps the program running.

It seems that for some reason the DMA ISR is never called and there is no audio i/o. I have setup a breakpoint inside the DMA ISR and the program never stops there. I am attaching a zip file my complete project. Can someone help me out with this? Do I need to setup anything else?

I should note that I have compiled and successfully run all the relevant examples that come with the CSL package. However, I am programming everything from scratch in order to have an audio i/o framework that I completely understand and I can use in future projects.

2677.audiotst_csl.zip

  • While still trying to debug this issue, I noticed that all the audio examples use DMA CH0, CH1 for transferring data to the codec and CH2, CH3 for receiving data from the codec. Is there some hardware restriction for this or is it just a convention?

    In my project I setup CH0, CH1 for receiving and CH2, CH3 for transferring? Could this be a problem?

  • Replying to myself once again, the setup of DMA0 channels as read/write does not seem to be important or I am missing something again.

    While trying to resolve the issue, I am watching the registers and it seems that DMA IFR is never out of 0x0000 that means no interrupt is called from DMA0, although DMA IER is 0x000F and the global DMA interrupt is enabled in IER0.

    Has anyone from TI looked into the project I attached? I thought that using CSL would provide some better support...

  • Hi Elias,

    I am also looking for an answer to this same problem. Any updates Elias?


    Regards, 
    Nate 

    p.s.  
     why do you recast the audio data array as a Uint32 (see your code below)
         configDMA.destAddr     = (Uint32)InputL;

    Why not just initially declare them as Uint32 instead of first creating them as Int16 and then casting them as Uint32? Also, it seems like if you are taking sample from the audio codec they should be signed, but I am no expert/post-doc!! Thanks! 

  • Hey Nate, unfortunately no updates. It seems for some reason that the DMA interrupt is never called, although I have enabled it using IRQ functions.

    As for the InputL declaration, since I am using DMA ping-pong mode the user's guide says that the ping and pong buffers must be consecutive and suggests to declare a single buffer that is double the size of each DMA transfer.

    The input buffer is Int16 because I need to do processing in 16bits signed. If I declared the buffer in Uint32 I would need to cast everytime I need to do processing. But now, I need to cast from Int16 to Uint32 just once when setting up the DMA.

  • Hi Elias,

    I was comparing your code to the code in the DMA_Ping_Pong example that comes with the CSL, and I noticed one particular difference in your ISR and their ISR:

    Their ISR includes the code:

    int ifrValue;
    ifrValue = CSL_SYSCTRL_REGS->DMAIFR;
    CSL_SYSCTRL_REGS->DMAIFR |= ifrValue;

     Your ISR does not include this code. I looked around on the forums and found this thread that explains how a guy named Todd Anderson used these lines of code to get his interrupts to be recurring. Then Henrik Gilvad, in the same thread, said:

    Henrik Gilvad said:

    Reading the Interrupt Flag Register remembers which interrupt-sources have triggered.
    Writing the bits in the CSL_SYSCTRL_REGS->DMAIFR clears the given interrupt(s) so they can occur again.

    So it's a handshake mechanism to tell that now we have serviced the interrupt and are ready for the next.


     

     I will try this out and see if I get good results, and I will report what I observe. 

    Also, I see in your code initializing the AIC the following lines:

    AIC_Write(0x34, 0x30); //IN2L routed to MICPGA (positive terminal) 40kOhm
    AIC_Write(0x37, 0x30); //IN2R routed to MICPGA (positive terminal) 40kOhm
    AIC_Write(0x36, 0x03); //CM2L routed to MICPGA (negative terminal) 40kOhm
    AIC_Write(0x39, 0x03); //CM2R routed to MICPGA (negative terminal) 40kOhm
    AIC_Write(0x3B, 0x00); //MICPGA (left) enabled, gain = 0dB
    AIC_Write(0x3C, 0x00); //MICPGA (right) enabled, gain = 0dB

    I am using the AIC3204, and I am not sure what audio codec you are using. If you are using the AIC3204, then I think these lines of code are attenuating your input signal by 12 dB (a loss of 12 dB / gain of -12 dB).  This is because you have the input impedance set to 40kOhms, and so if there is no gain in the MICPGA registers, the impedance will drop your signal by 12 dB. I dont know what audio you are feeding into your system, but I would like 0 dB of total gain, so i am changing the values in 0x3C and 0x3B from 0x00 to 0x18 = 0011000 =>  +12 dB gain => 0dB of net gain taking the impedance into account. 

    Just a small thing that should not affect the ISR from occurring. 


    Regards,
    Nate 

  • Hey Nate, thanks for putting some feedback in this discussion.

    First, concerning the AIC3204 you are right and I saw that some time after I posted the project and changed the settings.

    Second, concerning the code inside the interrupt the things you posted are interesting. However the code does not reach that point at all! So, still I am trying to solve the problem of getting into the interrupt. 

    I think I might drop the CSL and get back to simple register programming and see how this goes.

  • Elias Kokkinis said:

    Second, concerning the code inside the interrupt the things you posted are interesting. However the code does not reach that point at all! So, still I am trying to solve the problem of getting into the interrupt. 



    I will be investigating why the interrupt never happens over the next couple of days and will report my findings back here. I have to get this working for senior project. It really bugs me that TI has not replied to this post, because what we are trying to do seems so basic, and so universal - anybody wanting to do DSP with the C5000 series chips would probably want to set up DMA Ping Pong buffering with the audio codec. There should be some sort of template or at least a working example for the C5535...

    Elias Kokkinis said:

    I think I might drop the CSL and get back to simple register programming and see how this goes.



    Let me know if you have any luck! I will only touch register level programming as a last resort if I really cannot get the CSL to work.

    ALSO quoted from the technical reference (page 351): "Each I2S bus has access to one of the four DMA peripherals on the DSP: DMA0 <==> I2S0
    DMA1 <==> I2S2
    DMA2 <==> I2S3
    DMA3 <==> I2S1
    "
    I think you are okay with using DMA0 and I2S0, even though examples seem to use I2S2... I will personally be using I2S2 and DMA1, just to follow in the footsteps of examples im seeing. 

    Regards,
    Nate

  • Hi Elias,

    I noticed in your AIC3204 DAC setup the following line of code:


    AIC3204_rset(0x00, 0x00); //Select page 0

    ....

    AIC3204_rset(0x09, 0x30); //HPL, HPR power up

     

    register page 0 address 0x09 is a reserved register, not the HPL, HPR power up register. Just thought I would let you know since Im checking every line of code in our project.
    Page 1 must be selected before powering up HPL and HPR. 

    Also, if you are using the eZdsp C5535 kit from Spectrum Digital, you must use I2S channel 2 (I2S2). This is because channel 2 is hardwired to the AIC3204. 

    - Nate 

  • Hey Nate, I'll check the AIC code again.

    However I might have made progress and have the audio working with register programming. I'm checking how to also incorporate the HWAFFT and I'll post something today or tommorow, when I'm sure it works.

  • Hi Elias,

    That sounds great - I too might have some good results in the next couple of days using the CSL, and I will keep you updated.

    - Nate 

  • Update:
    I am successfully taking in audio through the stereo_in jack, and passing it directly  out through the stereo_out jack, using only the CSL! This means the I2S, I2C, and the PLL are all configured using the CSL, and the AIC3204 is properly programmed. 

    I had to build a complete understanding of how everything works together, and now I think I am ready to tackle the initial problem of DMA_Ping_Pong buffering using the CSL.
    I will report back when I am using the DMA properly!
    -Nate 

     

  • Nate, thanks for the update. I suppose you will be able to work through the DMA more quickly. I have a complete project without CSL that almost works, but there are some problems with the overlap-add section (which is something I never came to examine in the CSL project.)

    I will post an update on Monday, since I am out of office for the weekend (which is not always the case...)

  • Update: I have the DMA working in Ping Pong mode using the CSL (well, at least the ISR is entered)!! It's important to pair the correct DMA controller to the correct I2S channel. each DMA controller can only receive hardware sync/interrupt events from one unique I2S channel. If using the C5535 eZdsp from spectrum digital, then the AIC3204 (ADC/DAC module) WCLK (word clock) and BCLK  (bit clock) pins are connected (hard wired) to the I2S2_CLK and I2S2_FS  (clock pins for I2S channel 2) . Therefore DMA controller 1 must be used, and I2S2 must be used, if one wants to work with audio. 
    You probably already know this, I just want to inform others who might not already know this.
    The audio does not come through as you would expect, all I hear is a clicking sound. I will be working on fixing that issue.
    I can post my project here if you would like. 

    Elias Kokkinis said:

    there are some problems with the overlap-add section (which is something I never came to examine in the CSL project.)



    No problem for me - I do not think I will be using convolution, for this immediate project, but it would be good to know how to use it in the future. I am just planning to take a simple FFT (which as you know uses radix 2 implementation on the C5535).  

    Regards,
    Nathan 

     

  • Hello Nathan,

    I have started a new thread:

    http://e2e.ti.com/support/dsp/c5000/f/109/t/261883.aspx

    for my audio template project that uses register programming. I have tried to include as much documentation as possible. I hope it helps.