IRC48M Clock Synchronisation with USB

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IRC48M Clock Synchronisation with USB

Jump to solution
1,782 Views
mjbcswitzerland
Specialist V

Hi All

I am wondering whether someone has information about the IRC48M synchronisation accuracy to the USB (in devices with crystal-less USB support)?

The reason for asking is that I have done some tests concerning synchronising clocks derived from the IRC48M when USB is in operation and am interested in particular in USB Audio synchronisation.

For these tests I used an audio class streaming to either DAC output, PWM output (simplified DAC) and I2S based audio processr output. In each case the audio side clock is derived from the IRC48M (eg. PIT clock tme base to trigger conversions or audio processor time base).

If the IRC48M recovery is disabled so that it is not synchronised to the USB there is a quite high drift between the host USB clock (SOFs) - for example 1ms of drift every 2.5s.

With the recovery enabled the drift reduces to about 1ms in 1..2 minutes (slower than USB host clock). Typically it is however about 100us per second in a certain direction (slower). This does however fluctuate and it can be quite stable for a short period before drifting again. It can also drift in the other direction suddently for a short period, although this occurs quite rarely.

The hope was that on average the IRC48M (and this audio domain clock time base) would be synchronised to the USB host in order to achieve SYNC mode operation in audio class applications but this doesn't seem to be the case since the drift is still unacceptaby high.

Is this typical behavior and expected, or could something be incorrect in the measurements or the IRC48M synchronisation?

Regards

Mark

0 Kudos
1 Solution
1,030 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi Mark,

Sorry for the late reply! I just got the feedback from MCU R&D team, the information regarding IRC48M is as below:

The IRC48M in USB clock recovery modes adjusts the frequency of the internal IRC to the closest match of a number of quantized frequency ranges.  It does not do a phase lock at all and the frequency lock is approximate, guaranteed only to be within the +/-2500PPM of the implied frequency of the host based on the number of local 48MHz clocks relative to the interval between host SOF packets.

The IRC48M was never intended to be a precise clock/data synchronization method for USB audio devices.

so maybe you have to use another clock source for data synchronization, instead of the crystal-less solution.

Sorry for the inconvenience that has caused!


Have a great day,
Kan

NXP Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
7 Replies
1,030 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi Mark,

When IRC48 is used for USB device, the device will track the SOF which is sent by host to sync up with the host and avoid drifts, so how did you measure the drift ? Would you please share some register dump of USB module after the device is initialized? Thanks for your patience!


Have a great day,
Kan

NXP Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,030 Views
mjbcswitzerland
Specialist V

Hello Kan

Thank you for the interest in the case.

I have attached a binary which can be loaded to the FRDM-KL43Z which shows the effect.

The CPU is clocked directly from IRC48M and the bus clock is 24MHz (divided by 2).

The software configures a USB audio device so when you connect it to a PC it will appear as a microphon and speaker: Playing any music at the PC should send it to the device.

The USB has a buffer or 32 x 96 bytes so that it can receive 32 isochronous packates of 48 x 16 bit PCM every 1ms from the host.

PIT0 is configured to run at exactly 48MHz and triggers a DAC conversion (since its source is the bus clock it should be synchronised to the USB clock).

When USB starts the DAC is enabled after 16 isochronous packets have been received so that there is a 16 packet (16ms) delay between the USB data and the DAC output, whereby each DAC conversion triggers DMA which performs continuous circular buffer transfers from the USB buffer to the DAC.

Connecting a speaker to the DAC output (PTE30 = J4-11), the music is heard and has good quality for usually 5 minues or so.

Occasionally (eg. roughly every 5 minutes) there is usually a period of around 10..20s where the music is badly distorted and there is a lot of noise - this happens when the DMA is copying the area in the USB buffer which is presently being filled by the USB reception. The original 16ms delay has either drifted to 32ms or reduced to 0ms to cause this.

PTC7 - J1-11 is driven by audio_USB_SOF_OUT so that the SOF on the USB bus can be monitored as reference.

PTD5 - (green LED) - J2-12 is initially at '1' but is set to 0 on the first USB buffer reception and then repeatedly each subsequent 32 buffers (once every 32ms).

The output is set to '1' each time the DMA circular buffer transfer completes (also every 32ms)

The result is that at USB connection there is a square wave with the falling edge indicating the first USB buffer reception and the rising edge the DMA buffer transfer completion. The falling edge (USB reception interrupt) is synchronous to the SOF output pulse (delayed by 84us).

If the USB host were perfectly synchronous to the IRC48M this square wave would remain stable overtime but this is not the case - the mark-space ratio drifts slightly with time - mainly in a certain direction with a gradual drift, although sometimes the drift speeds up for a short time and sometimes the drift changes direction for a short time too. Sometimes there are even quite long periods where the drift is virtually zero too.

Most of the time the circular buffer interrupt will drift 2ms slower every 14s and the drift is easily monitored with an oscillocope.

If I speed the PIT up slightly (0x1f2 instead of 0x1f3) the DMA buffer drifts faster at about +2ms every s.

If I slow the PIT slightly (0x1f4 instead of 0x1f3) the DMA buffer drifts slower at about -2ms every s.

The PIT clock is the bus clock and so is synchronous to IRC48M and this also shows that its 48kHz setting is optimal.

To do this experiment the memory modify command can be used in the I/O menu on the OpenSDA virtual COM port at 115200Baud:

"mm 40037100 l 1f3"

In fact it is quite simple to keep the USB synchronised with the audio output by using

"mm 40037100 l 1f2" or "mm 40037100 l 1f4" to cause a temporary drift to synchronise the signals before they drift to a critical phase.

Intially I thought that the DMA buffer interrupt, which needs to set up the next DMA buffer transfer, was the problem because it could lose a sample in the process (it must prepare the next transfer within 20.8us to ensure not missing a sample) but if it did always miss a sample it would result on a drift of 20us every 32ms (312us/s) and not the  typical 140us/s. The fact that the drift sometimes stops and even goes in the opposite direction tends to confirm that this is not the case.

Another method of monitoring the drift is to use the "delta" command in the USB menu. This will show the present deviation (each time requested [repeat last command using the up-arrow]) from the ideal delay in us and thus also drifts between -16000us and +16000us. When the drift is at an extreme there can be noise and as long as it remains in the +-15000 range the music is of good quality.

Eg.

Command "delta" shows

Delta = -700us

The following are relevant configurations with regard to the crystal-less USB device operation:

SIM_SOPT2 |= (SIM_SOPT2_USBSRC | SIM_SOPT2_PLLFLLSEL_IRC48M); // set the source to IRC48M - value = 0x0404000

USB_CLK_RECOVER_IRC_EN = USB_CLK_RECOVER_IRC_EN_IRC_EN; // enable 48MHz IRC clock and clock recovery - value = 0x02

USB_CLK_RECOVER_CTRL = USB_CLK_RECOVER_CTRL_CLOCK_RECOVER_EN; // value = 0x80

Finally, here is a screen shot of the USB registers when paused during the operation.

pastedImage_0.png

I can operate for long periods of time with the USB without any USB difficulties - the drift is the only problem. This tends to suggest that there is crystal-less synchronisation for reliable USB but the synchronisation is not adequate to actually lock the IRC48M to the host time base.

I look forward to your evaluation.

Regards

Mark

0 Kudos
1,030 Views
mjbcswitzerland
Specialist V

Kan

I have some additional references.

1. uTaskerV1.4.11_FRDM_KL43Z_USB-Audio_SW-PLL.bin

This version has a SW PLL enabled which adjusts the PIT frequency slightly when the deviation between the USB and DMA interrupts leaves the ideal region and so results in a software PLL operatio to keep the time bases well synchronised.

2. uTaskerV1.4.11_FRDM_KL26Z_USB-Audio.bin

This is the exact same application for the FRDM-KL26. The difference is however that the KL26 doesn't have IRC48M and crystal-less USB device operation all device timing is based on it crystal time base.

The monitoring output is on PTE28, which is pin 1 on the RED LED.

Audio_USB_SOF_OUT is enabled on PTC7 (J1-1)

The DAC output signal is on the connector J4-11

Without any SW PLL I measure a drift of 500us in one minute (138ns/s) which is much lower than the IRC48M case and will depend on teh absoute accuracy of the crystal so probably varies slightly between boards.

This however confirms that there is no drift due to sample loss since the drift is extremely constant (doesn't change direction or vary in speed as in case of the KL43).

3. uTaskerV1.4.11_FRDM_KL26Z_USB-Audio_SW-PLL.bin

The same KL26 version with the SW PLL enabled to ensure full host and device time base synchronisation.

Preliminary conclusion:

  • As long as there is no error in the use of the crystal-less USB operation this shows that the SOF synchronisation may be adequate for USB device compliance but not so for USB Audio class without additional time base synchronisation techniques.
  • It is however fairly simple to monitor drift in software and create a software PLL to ensure long term accuracy in the test case.
  • In other cases, where the I2S is used, there can be additional complications since audio processor chips may be using a processor reference for its own PLL or FLL time base which is not necessarily so easy to influence to create a SW based PLL. In this case it was hoped that the Crystal-less capability would be a natural solution, which presently hasn't been the case.
  • Note finally that the main impetus for the work was that the KSDK audio class suffers from the same effects and it doesn't look like there is a solution integrated in the framework. See aso USB audio generator

Regards

Mark

0 Kudos
1,030 Views
mjbcswitzerland
Specialist V

Hi

Are there any comments on the results obtained?

As comparison I have attached a FRDM-K64F version.

This also uses the crystal-less USB device mode but at the same time has TCP/IP operation on the Ethernet (although this doesn't influence in any way) as well as RNDIS composite so that it also appears as a USB-Ethernet adapter with its own TCP/IP interface as well as the audio device - again the RNDIS composite operation doesn't influence and so operation and synchronisation results are equivalent.

The DAC output is on J4-11 and the monitoring output is on J1-2.

Once again, one version with SW PLL and one without.

Regards

Mark

0 Kudos
1,030 Views
mjbcswitzerland
Specialist V

Ping...

Any ideas?

0 Kudos
1,031 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi Mark,

Sorry for the late reply! I just got the feedback from MCU R&D team, the information regarding IRC48M is as below:

The IRC48M in USB clock recovery modes adjusts the frequency of the internal IRC to the closest match of a number of quantized frequency ranges.  It does not do a phase lock at all and the frequency lock is approximate, guaranteed only to be within the +/-2500PPM of the implied frequency of the host based on the number of local 48MHz clocks relative to the interval between host SOF packets.

The IRC48M was never intended to be a precise clock/data synchronization method for USB audio devices.

so maybe you have to use another clock source for data synchronization, instead of the crystal-less solution.

Sorry for the inconvenience that has caused!


Have a great day,
Kan

NXP Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,030 Views
mjbcswitzerland
Specialist V

Hello Kan

Thank you. This is the confirmation that was required - it matches with practical operation and confirms that the results obtained are as expected and not due to some other difficulty.

From the product dvelopment in question it has been experienced that the crystal-less synchronistion is not adequate for synchronous USB audio class operation and so other techniques are being used instead.

Regards

Mark

0 Kudos