Conducted emissions using the CCM_CLKO1 with SGTL5000.

[joshbarnheiser]

On my custom board I am using the SGTL5000 audio codec and feeding its SYS_MCLK pin with the CCM_CLKO1 signal of the i.MX6. When I test for conducted emissions I get around 27 dBuV at 72 MHz, when the surrounding frequencies are down below 20 dBuV. From turning things off I have found the 24 MHz clock from CCM_CLKO1 to be the problem. I changed the CCM Clock Output Source Register from 0x010e017b to 0x010e00A4 to try to move the radiation to around 27 MHz.

This worked successfully and the radiation didn't even show up at 27 MHz. The SGTL5000 seemed to load fine, but when I tried to play a test file, that had previously worked fine, there was no audio. I am not sure if there is something that needs to be done with the SGTL5000 to get it working with the lower frequency or if there is something else that can be done with the iMX6.

Has anyone else experienced emissions with the SGTL5000?

[igorpadykov · Accepted solution]

Hi Josh

seems changes in CCM Clock Output Source Register changed

bit8 CLK_OUT_SEL in register CCM_CCOSR described in
sect.18.6.21 CCM Clock Output Source Register (CCM_CCOSR)
i.MX6DQ Reference Manual (rev.4  9/2017)
http://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf

So frequency can be adjusted to previous value using bsp sources for example

in boundary devices releases where supported sgtl5000:
uboot/board/boundary/nitrogen6x/nitrogen6x.c

In general for emissions one can try to tweak drive strength pads

which produce that signal, like GPIO_0 [ALT0 CCM_CLKO1], CSI0_MCLK [ALT3 CCM_CLKO1]

and others.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[joshbarnheiser]

Thank you for your response Igor.

I will look into changing the DSE bits of GPIO_0's pad control register.

I was using devregs, a tool on github for accessing registers from userspace, to change the CCM_CCOSR register. I don't know if it would affect the processor differently setting the register in user space as opposed to u-boot, but it is quicker for me when testing things out.

https://github.com/boundarydevices/devregs

I have to charge the battery before I can test again, but I will update this post when I've tested some more.

UPDATE: I was able to improve it a little by increasing the impedance set by the DSE. Setting DSE to 1 worked best for me. We still have a spike of 23 dBuV, but it did lower it.

Josh