• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1004 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

OMAP4460 McPDM Audio noise problem

Dinesh Guni1
Prodigy 165 points

Other Parts Discussed in Thread: TWL6030, TWL6040

Hi,
 
We have an audio issue in OMAP4460 customized board. We are using OMAP4460 + TWL6040 + TWL6030 as similar to the Panda board architecture, In our custom proto board we have used 33E series resistor in the McPDM lines. We observed audio noise ( Along with the sound  we can hear noise).  After replacing 33E resistor with 0E resistor we are able to eliminate the noise from the audio.
 
In the new build even with 0E series resistor in the McPDM line we are observing the audio noise. Now we are observing the noise only in the DL0 (DownLink 0 - Headset output). There is no noise present in DL2(Speaker output). Is there any difference in DL0 and DL2 channel?
 
While debugging the issue we have found few registers which are related to 50-Ω Output Buffer I/Os with Combined Mode and Load Settings ( CONTROL_SMART3IO_PADCONF_1 [7:6] and CONTROL_SMART3IO_PADCONF_2 [7] , TRM Version M reference Page No. 3520 ).

We are noticing changes in the noise level when these registers configured for different modes. We need to understand the significance of these mode settings, can you please point to some application note which gives the idea about drive strength and mode settings.

One more observation is that when we disable the SMARTREFLEX(SR) in the kernel we are not observing the noise in DL0(Headset). Just wondering how SmartReflex has impact on this audio noise issue?

Thanks and Regards,
Dinesh Guni 
 
  • 0
    TI__Mastermind 29520 points

    Hello Dinesh,

    At first I will suggest to apply this workaround in your McPDM driver from OMAP4470 ERRATA document - i635 Presence of a Floor Noise on Audio Band When Multiple McPDM Downlink Enabled.

    Case 1 workaround for transfer 6 downlink channels of McPDM: • Set McPDM downlink FIFO threshold to 2 (floor noise goes back to ~ -130dB_fullscale), or set 0x2 in the bit-field MCPDM_FIFO_CTRL_DN[3:0] DN_TRESH  FIFO downlink threshold value.

    Case 2 workaround for transfer 4 downlink channels of McPDM: • Set McPDM downlink FIFO threshold to 4 (floor noise goes back to ~ -130dB_fullscale), or set 0x4 in the bit-field MCPDM_FIFO_CTRL_DN[3:0] DN_TRESH  FIFO downlink threshold value

    Check the suggested workaround, it is possible to solve your issue with McPDM.

    Best regards,

    Yanko

  • 0 in reply to Yanko Todorov-XID
    Prodigy 165 points
    Dear Yanko,
     
    Thanks for the reply. We tried to implement the suggested workaround but it did not solve the problem. With Case 2 workaround even we are not able to hear the audio.
     
    Presently in the kernal MCPDM_FIFO_CTRL_DN[3:0] is set to 0x2. We tried to set it to 0x4 as explained in Case2 but after this change we are not able to hear audio.
     
    To beifly explain our use case we have speaker and headset in our system and only one will be active at any given time based on headset detect. So we are enabling only ONE downlink channel in McPDM. Is there any relation between number downlink channel enabled and Down link FIFO threshold? In such case can you give us optimal settings for the FIFO threshold value for our use case ( Headset(DL1) + speaker(DL2) only One active at a time.)
     
    Other part of our observation is that we are seeing different behavior with respect to SmartReflex. SmartReflex disabled board will play audio without noise and same board when we enable the SmartReflex we are getting noise in the audio. Inline to these we are also observing change in noise level with respect to CPU governor settings. Can you explain us the relation between SmartReflex and McPDM audio interface?
     
    Thanks and Regards,
    Dinesh Guni
     
     
  • 0 in reply to Dinesh Guni1
    TI__Mastermind 22945 points

    Dinesh,

     

    Just in case.

    The TWL604x bug "#7 PDM Downlink Data Corrupted" is taken care ?

     

    Depending on the delay between PDMCLK (provided by TWL604x) and PDMCLKLB (provided by OMAP),

    the data transmitted to the TWL604x DACs can be corrupted.

     

    Please contact your local TI representative to get TWL604x Errata document.

     

    Thanks and regards,

    Koichiro Tashiro

  • 0 in reply to Dinesh Guni1
    TI__Mastermind 29520 points

    Hello Dinesh,

    The similar problem is described in OMAP5 ERRATA document - http://www.ti.com/lit/er/swpz037b/swpz037b.pdf

    Errata ID: i800 - "McPDM Downlink Data Corrupted With TWL604x" The suggested guideline is following: An inverter is placed on the board between TWL604x.PDMCLK and the OMAP abe_clks pad. The inverter (for example, SN74AUC1G04DCK) must be placed close to TWL604x on the PCB.

    Depending on the delay between abe_clks provided by TWL604x and the loopback clock abe_pdm_lb_clk from OMAP, the data transmitted to TWL604x DACs can be corrupted. As a result, the output noise of the analog output stages can increase.

    About your questions:

    1. The FIFO downlink is read by the McPDM module and data related to the audio downlink channels are
    sent to the delta-sigma modulators. The maximum number of write accesses (before overwriting the data in the FIFO still to be transmitted) from the host/DMA is determined by the following equation:
    Num_max_write_access = (FIFO_SIZE – DN_THRESH + 1) * (PDM_DN1_EN + PDM_DN2_EN + PDM_DN3_EN + PDM_DN4_EN + PDM_DN5_EN +CMD_INT). For more information refer to section 23.6.4.8.2 Downlink Path Description in OMAP4470 TRM.

    2. I think there is not a relation between SmartReflex and McPDM audio interface. The noise can be caused by ripples onsignals from PMIC. For more information see section 3.10.4.1.4.1   Subsequence – Error-to-Voltage Converter Configuration in OMAP4 TRM.

    I suggest to apply the workaround from i800 OMAP5 ERRATA if possibly.

    Best regards,

    Yanko