the problem is the output signal is shutdown, waiting help,thanks

If you have a simple question and just want an answer.
superganbu
Member++
Posts: 21
Joined: Thu Dec 07, 2017 3:27 am

the problem is the output signal is shutdown, waiting help,thanks

Post by superganbu »

Hi all
We need your help for this problem:
We have a sound card with the XMOS technology, 8input,8output;
the card is work, but sometimes the AUDIO output will shutdown, and it cannt get well untill power reset。
the input is OK, there is no signal in the TDM pin which is connect to DAC(use the oscilloscope ),but the input pin form adc is good and there is wave on pc。

It seems that the problem is not a soft problem, because there is much worse in the production line than in the lab;

waiting for your help,

thanks a lot!


superganbu
Member++
Posts: 21
Joined: Thu Dec 07, 2017 3:27 am

Post by superganbu »

we found that there is no data form ep_aud_out; we cant recevie any data from PC, but at windows it looks like work well.

why the fun XUD_GetData_Select cant get any data? the ep_aud_out shutdown ? any reason?



/* Received Audio packet HOST -> DEVICE. Datalength written to length */
case XUD_GetData_Select(c_aud_out, ep_aud_out, length, result):
{
GET_SHARED_GLOBAL(aud_from_host_buffer, g_aud_from_host_buffer);

write_via_xc_ptr(aud_from_host_buffer, length);

/* Sync with decouple thread */
SET_SHARED_GLOBAL0(g_aud_from_host_flag, 1);
}
break;
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. First of all, not an audio developer but have helped many OEMs to get their custom XMOS designs working.

1) Is this a custom XMOS design?

2) Have you tested this custom PCB using a known good, XMOS USB High Speed IP? For example, the USB HID Mouse example? This mouse example is simple to compile and should be applied to your custom PCB to validate that the USB traffic is solid. The mouse on your screen will move in a rectangle pattern and continue to do so till stopped. Run this for a few hours to confirm that you are not facing any PCB impedance control / layout issues, etc.

On the PCB layout, you must design the PCB to support impedance controlled traces for USB High speed (90 ohms) and these traces must be identified to the PCB company so that they offer proof of the support with a TDR report. Otherwise, you are taking your chances on if the design will be stable out in the field with the very varying quality of USB cables.

3) Moving forward, most likely you are fine with the above..did you remove the code runs to non-existing I2C hardware from your XMOS IP? This is a common and root cause of the symptoms you are raising. That is, the USB IP is limited to the bandwidth available inside each CPU thread. If the thread is blocked due to repeated I2C calls to hardware that is not present on your design (ie. believe it is like 2000 retries before leaving the code run), the USB IP and possibly other features will suffer. Then only a cold reset will restore the operation.

Please confirm the above and post your status again.
superganbu
Member++
Posts: 21
Joined: Thu Dec 07, 2017 3:27 am

Post by superganbu »

1) Is this a custom XMOS design?

yes, we design the soundcard and use it in our factory.

2) Have you tested this custom PCB using a known good, XMOS USB High Speed IP? For example, the USB HID Mouse example? This mouse example is simple to compile and should be applied to your custom PCB to validate that the USB traffic is solid. The mouse on your screen will move in a rectangle pattern and continue to do so till stopped. Run this for a few hours to confirm that you are not facing any PCB impedance control / layout issues, etc.
No, we didnt test the USB traffic.
But, in the design, we have one hid ep, one IN ep for sound record, one OUT ep for display sound, when the problem accur, the OUT ep cant receive data , but the IN ep and
HID EP are working well,
So , can we believe thar it isnt a hardware problem? does the OUT ep stop work for any reason?
Another usefull information is the problem only occur when communication on the bus. when stop playing sound, keep a long time, and then play again, it will work well.

On the PCB layout, you must design the PCB to support impedance controlled traces for USB High speed (90 ohms) and these traces must be identified to the PCB company so that they offer proof of the support with a TDR report. Otherwise, you are taking your chances on if the design will be stable out in the field with the very varying quality of USB cables.
Good ,we will take the advice.

3) Moving forward, most likely you are fine with the above..did you remove the code runs to non-existing I2C hardware from your XMOS IP? This is a common and root cause of the symptoms you are raising. That is, the USB IP is limited to the bandwidth available inside each CPU thread. If the thread is blocked due to repeated I2C calls to hardware that is not present on your design (ie. believe it is like 2000 retries before leaving the code run), the USB IP and possibly other features will suffer. Then only a cold reset will restore the operation.

When playing sound ,there isnt I2C communication


Please confirm the above and post your status again.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

When playing sound ,there isnt I2C communication

Please clarify this comment. On your custom board, do you have I2C based DAC / ADC for the audio in / out functions? Or are you stating that in the lock up state, the I2C traffic then stops?

On this topic, have you masked out all routines that may be calling I2C hardware that is NOT on your board? The constant retry of missing I2C hardware will cause these issues.

Suggest to run AN00129 - USB HID MOUSE (runs using USB High Speed interface) on your custom PCB to validate that the PCB functions as a mouse. Let this demo run for an hour or so the PCB layout can be ruled out.



Also, read this thread to see if it helps:

https://www.xcore.com/viewtopic.php?t=4685
superganbu
Member++
Posts: 21
Joined: Thu Dec 07, 2017 3:27 am

Post by superganbu »

We have checked all the I2C, it has no problem.
We check the xud receive memory, the data has received, but only the interrupt isnt happen, that is the fun below didnt execute. any advice for enable the Interrupt or keep it working?

ENABLE_INTERRUPTS() is no use for the problem,we have tested.


case XUD_GetData_Select(c_aud_out, ep_aud_out, length, result):
{
GET_SHARED_GLOBAL(aud_from_host_buffer, g_aud_from_host_buffer);

write_via_xc_ptr(aud_from_host_buffer, length);

/* Sync with decouple thread */
SET_SHARED_GLOBAL0(g_aud_from_host_flag, 1);
}
break;
User avatar
ccrome
Active Member
Posts: 62
Joined: Wed Sep 23, 2015 1:15 am

Post by ccrome »

We have exactly this same problem. It's a custom board, but the XUD_GetData_Select stops getting called, kind of randomly. I cannot figure out why. Did you ever resolve the problem?

BTW, this has nothing to do with I2C. It's way back in the XUD layer -- XUD itself seems to stop calling XUD_GetData_Select(), so the usb_buffer.xc never receives the packets. However, the packets *ARE* being sent on the USB wire. I verified that with a USB sniffer.


Thanks,
- Caleb
superganbu
Member++
Posts: 21
Joined: Thu Dec 07, 2017 3:27 am

Post by superganbu »

Hi
We find a method to fix the problem by software,we check the Received data when playing,when no data received ,we restart the usb data stream,if anyone need help , I can share the details。
User avatar
ccrome
Active Member
Posts: 62
Joined: Wed Sep 23, 2015 1:15 am

Post by ccrome »

Some details would be great to know!

Thanks!
Jrodrigo
New User
Posts: 2
Joined: Fri Feb 02, 2024 6:02 am

Post by Jrodrigo »

Hi all,

We are having the same issue. The XUD_GetData_Select function is not called again anymore although upstream USB traffic still working and downstream USB audio frames are arriving to XMOS.

We are going to run the HID Code to test the board, but we would really appreciate more info about how to detect the lost and reset the USB IP you commented.

Regards
Post Reply