How fix the master clock absence

[mbrico]

Hi All,

I'm new of xmos world and I have an issue with my xMos project.
I use the two clocks 22.579MHz and 24.576MHz to select the Master Clock (p_mclk_in).
The xMos is powerd by Vbus, but the circuit which selects the clock is powered with an external power supply.
If the external power supply is turned on before that the usb cable is connected to a pc, then everything works fine.
But if the usb cable is connected and the external power supply is turned off, then the Master Clock is not present into the xMos and when we play an audio file with Foobar2000, we get the error: "Unrecoverable playback error: Could not set sample rate to 96000 Hz".
This is normal because the MCLK is not present.
If the external power supply is turned on after that the usb cable has been connected the error persists, we necessarily have to unplug the USB cable and reconnect it.

I don't know how to fix it.

How can I trap the error of the absence of the master clock to avoid disconnecting the USB cable?

Have you any suggestion?

Regards,

Fabio

[infiniteimprobability]

As you say - absence of MCLK will cause issues. The audio subsystem main loop (audio.xc) is clocked via MCLK so without it, it will not service the channel end on decouple (decouple.xc). This means decouple will block and it won't be able to service sample rate changes.. Due to the synchronised nature of channel communication, it may well block other tasks.

Anyhow, what you obviously need is to have a valid MCLK before the code runs. Two initial ways I can think of to do this:

1) Modify your hardware so that the reset line is not de-asserted until the external PSU is present. This will ensure it doesn't come up unless the MCLK is in place

2) Modify the code so that absence of an MCLK causes a reset. The chip will go around a reset cycle util MCLK starts toggling - it won't harm anything although possibly may cause clicks/pops depending on how your HW is setup.
This method would need a little investigation to see exactly which tasks block when no MCLK is present (check using debugger and see if you are blocked on a channel operation :> or <: ). If buffer.xc (usb_buffer.xc) is still running, then some code in there to check the MCLK count is increasing would make sense - look around this section:

Code: Select all

 /* Get MCLK count */
 asm (" getts %0, res[%1]" : "=r" (u_tmp) : "r" (p_off_mclk));

then

Code: Select all

<add some code to call reboot if  u_tmp doesn't change>

To reboot, there is code in reboot.xc (used during DFU) to do the soft reset..

If buffer.xc is blocked, then see if there are any other tasks still running - if so do the get MCLK count in that instead. If you are really stuck (all cores get blocked without MCLK) then it may be necessary to add an additional task that does the monitoring of MCLK..

Another idea might be to modify the clock blocks so that the MCLK one (clk_audio_mclk) uses the ref clock initially until u_tmp starts incrementing, whereupon it switches to external MCLK.

So doable, if a little fiddly/hacky...

The HW approach is probably the proper way to fix this.

[bafio]

Hi,

thank you for your help!
I solved the problem adding code in "usb_buffer.xc" to call reboot if u_tmp doesn't change.

Code: Select all

.....
unsigned u_tmp_old = 0;
unsigned CheckMCLK = 0;
....


 /* Get MCLK count */
 asm (" getts %0, res[%1]" : "=r" (u_tmp) : "r" (p_off_mclk));

if (u_tmp_old != u_tmp)    {
         u_tmp_old = u_tmp;         
         CheckMCLK = 1;      
         }                                                   

if (CheckMCLK != 0) CheckMCLK++;              

if ((CheckMCLK > 10)&(u_tmp_old == u_tmp))      
         device_reboot();                                   
.....

You are the best!

[infiniteimprobability]

Great news! I'm glad the suggestion worked.

Thanks for the feedback and for sharing your code changes with others.