Post Go back to editing

Example project in SAM_BareMetal_SDK-Rel2.1.2

Category: Software
Product Number: SC589-MINI, A2B AD2428
Software Version: SAM_BareMetal_SDK-Rel2.1.2

I have taken example project for SAM board(C:\Analog Devices\SAM_BareMetal_SDK-Rel2.1.2\framework) and customized based on the setup I am using.

I am using SAM as Main Node and SC594(SOM Carrier EZ-Kit + SC594-SOM + AD2428_Mini) as sub-node1. Please find the image of setup as below

I am planning to receive 2 channels from SAM board to SC594 setup through A2B

Customization Done in code is as below

1. I have made ENABLE_A2B macro as true in the file audio_system_config.h

2. In processaudio_callback() function I have added below lines in for loop to copy data from ADC to A2B.
//Send audio in from ADAU1761 to the A2B bus
audiochannel_a2b_0_left_out[i] = audiochannel_0_left_in[i];
audiochannel_a2b_0_right_out[i] = audiochannel_0_right_in[i];

3. I have also modified schematics and exported Command list file and used it in project. Please find the updated schematics attached(A2B Topology (4down-TDM8) SAM-ClassD.zip)

When I provide sine tone to SAM board and tried to halt the code in SC594 and check the DMA buffer I am not getting the sine tone. I am getting plot as below

Schematics

A2B Topology (4down-TDM8) SAM-ClassD.zip

Please find the source code running in SC594 board attached

SC594_A2B_Rx_Tx_ARM_Core0.zip

Please let me know your feedback on this

Parents
  • Hello,

    Just a quick question to start. Are you seeing the sine wave correctly if looking at the plot on the SC589? Or you could also send the ADC input to the DAC output on the SC589 and see if you hear a sine wave as well. It would be nice to at least rule out if there is any issues on the SC589 side.

    Regards,

    Chad

  • Yes I have checked the Loopback(ADC-DAC). Its working fine. Also I have plotted DMA buffers of A2B Tx in SC589-MINI. It looks proper sine wave

  • Hi Sivark,

    Can you share your SAM FW code too? Another thing you can do is to loop back audio from sam to 594 then back to sam by connecting a2b->594 data pin to 594->a2b data pin in your 594 framework SRU config. If you get good audio, then a2b bus configs are good. If not, should look into a2b configs first.

    I reviewed your 594 sport ISR code. not sure if I understand it correctly. 

    static void SPORTCallbackRx(
    void *pAppHandle,
    uint32_t nEvent,
    void *pArg
    )
    {
    ADI_SPORT_RESULT eResult;

    switch (nEvent)
    {
    case ADI_SPORT_EVENT_RX_BUFFER_PROCESSED: CallbackCount1++; // CallbackCount1 increase by 1. it is zero after init and becomes 1 here
    //CallbackCount1 = (CallbackCount1%2);
    Transfer_data();
    //FlowControl(read_p,write_p);
    break;

    default: break;
    }
    }

    void Transfer_data(void)
    {
    if(CallbackCount1==0) // CallbackCount1 has no chance to be equal to zero
    {
    for(i=0;i<DMA_BUF_SIZE;i++)
    {
    DestDataBuf3[i]=DestDataBuf1[i];/*Copy ADC buffer to DAC buffer */
    }
    }

    if(CallbackCount1==1) // CallbackCount1 is one, execute
    {
    for(i=0;i<DMA_BUF_SIZE;i++)
    {
    DestDataBuf4[i]=DestDataBuf1[i];/* Copy ADC buffer to DAC buffers */
    }
    CallbackCount1=0; // CallbackCount1 is set to zero
    }
    }

    CallbackCount1 is always 1 in Transfer_data. If this is true, you always copy samples from DestDataBuf1 to another buffer in the SPORT ISR. DestDataBuf1 and DestDataBuf2 are SPORT RX ping-pong buffers so it seems you are competing with SPORT DMA to access DestDataBuf1. Should double confirm the above code is intended before debugging. 

Reply
  • Hi Sivark,

    Can you share your SAM FW code too? Another thing you can do is to loop back audio from sam to 594 then back to sam by connecting a2b->594 data pin to 594->a2b data pin in your 594 framework SRU config. If you get good audio, then a2b bus configs are good. If not, should look into a2b configs first.

    I reviewed your 594 sport ISR code. not sure if I understand it correctly. 

    static void SPORTCallbackRx(
    void *pAppHandle,
    uint32_t nEvent,
    void *pArg
    )
    {
    ADI_SPORT_RESULT eResult;

    switch (nEvent)
    {
    case ADI_SPORT_EVENT_RX_BUFFER_PROCESSED: CallbackCount1++; // CallbackCount1 increase by 1. it is zero after init and becomes 1 here
    //CallbackCount1 = (CallbackCount1%2);
    Transfer_data();
    //FlowControl(read_p,write_p);
    break;

    default: break;
    }
    }

    void Transfer_data(void)
    {
    if(CallbackCount1==0) // CallbackCount1 has no chance to be equal to zero
    {
    for(i=0;i<DMA_BUF_SIZE;i++)
    {
    DestDataBuf3[i]=DestDataBuf1[i];/*Copy ADC buffer to DAC buffer */
    }
    }

    if(CallbackCount1==1) // CallbackCount1 is one, execute
    {
    for(i=0;i<DMA_BUF_SIZE;i++)
    {
    DestDataBuf4[i]=DestDataBuf1[i];/* Copy ADC buffer to DAC buffers */
    }
    CallbackCount1=0; // CallbackCount1 is set to zero
    }
    }

    CallbackCount1 is always 1 in Transfer_data. If this is true, you always copy samples from DestDataBuf1 to another buffer in the SPORT ISR. DestDataBuf1 and DestDataBuf2 are SPORT RX ping-pong buffers so it seems you are competing with SPORT DMA to access DestDataBuf1. Should double confirm the above code is intended before debugging. 

Children
No Data