Migrating to lib_xud with UAC2 reference implementation

[Zdenek151]

Dear all,

in our product, we are using xu216 and the xmos uac2 reference implementation. We upgraded to lib_xud and we are experiencing issues with resets to and from the dfu mode on M1 MACs. Originally, we downgraded sc_xud, which seemed to helped with this particular issue, but introduced a host of other issues elsewhere. We have usb on tile[1] and use 6 cores. I tried fiddling around with the values in DfuDelay with no particular success.

Has anyone seen something like this?

Thanks

[xross]

Have you tried the 7.2.0 USB Audio release?

[Zdenek151]

Hi xross,

thanks for responding. Unfortunately, updating to 7.2.0 is not an option for the current project. We are stuck with 6.15.2 with updated lib_xud 2.2.2.

Our problem is that once we get a fw version trough testing, any further change, even in a completely unrelated code can break it again. The device is just not recognized again after reset into dfu.

I was just curious if anyone experienced anything like this on M1 Macs.

[xross]

Do you have a USB trace at all? I actually have an M1 Mac as my main machine and we have one in our regression setup. Note, there is a 2.2.3 release though not sure that will help, but worth a try.

[Zdenek151]

As soon as we connect an usb analyzer between the device and the M1 Mac, the issue can't be reproduced anymore. Also connecting the device trough a powered hub helps. Thanks. I'll give 2.2.3 a try.

[xross]

Is this a self or bus-powered device?

[Zdenek151]

It is kind of both. The external power-supply is optional. SELF_POWERED define is 0 though. The M1 issue is happening regardless.

[xross]

I see, you'll be breaking the USB spec in self-powered mode since you won't be detecting whether VBus is present before applying the D+ pull-up I guess (see "USB back voltage"). Possibly un-related to this issue though.

[Zdenek151]

Good to know. Is there a way how to do this properly? I guess UAC2 reference implementation does not support this out of the box. We encountered some other issues with SELF_POWERED set to 1.

[Zdenek151]

Just heard back from the testers that upgrading to lib_xud2.2.3 didn't help the M1 reset into dfu issue. It was working with the previous release, then I made a tiny change in an unrelated code and it is failing.

[xross]

Please post the result of xrun -dumpstate .xe in the broken state

They analyser effecting things might indicate a signally or power problem. However, the change in unrelated code doesn't really fit with this.

[Zdenek151]

Hi Ross, I enclose the dump. lib_xud 2.2.2

M1_resettodfu_fails_xmos_dump.txt

lib_xud/src/core/XUD_DeviceAttach.xc:88 is this line: 88: flag2_port :> tmp;

EDIT: Here are usb traces when it works and when doesn't. The testers managed to reproduce it with the analyzer connected after all. Resetintodfu packet is on line 411 M1_resettodfu_success_trace.csv Resetintodfu is on line 352 M1_resettodfu_error_trace.csv

[xross]

It looks like the high-speed handshaking has failed after the reboot. How often does this occur please?
Do you have the original .tdc files please, rather than exported .csv files (I have access to a few analysers and TotalPhase is one of them). Thanks.

[Zdenek151]

We have fw builds where it works almost always, some builds work 7/10 attempts, some always fail. This varies depending on the fw change I do.

EDIT: Here are the traces as tcl files: tcl_trace.zip

[Zdenek151]

Hi ross, any idea what we could measure/check/try to make this more predictable? Thanks!

[xross]

Is it possible to reproduce on an XMOS dev kit at all? Are you always testing in the bus-powered configuration?

[Zdenek151]

Yes, we are always testing with bus-powered configuration. Reproducing that on XMOS dev kit would be difficult.

[xross]

It appears that the high speed handshake signalling is failing for unknown reason. Why changing unrelated code should effect this is troubling and unclear. My experience in these issues is that they normally require more information that you can get from a usb analyser I.e. using a oscilloscope on the d+/d- lines to see exactly what is going on. Our regression has dfu tests passing on a m1 on both xs2 and xs3 on a nightly basis - this is a different usb audio codebase of course.

If it possible to check a standard release of usb audio on the problematic mac?

[xross]

On the unrelated code front can you go back and forth between binaries and replicate the same failure rate? I.e. it's not the how's changing its behaviour?

[Zdenek151]

Thank you. I understand. It may very well depend on our hardware.

If it possible to check a standard release of usb audio on the problematic mac?

Possible yes, but not in the current time frame.

[Zdenek151]

Seems like setting set_core_high_priority_on(); in the XUD_Manager core helps. The issue can't be reproduced anymore. Hopefully this will last. We have 6 cores on tile[1]. We still have an issue that the device is not recognized after resetting from DFU, but that is much less severe. BTW: We are not sending RESETFROMDFU, because the device is not manifestation tolerant and resets itself when it is done.

[xross]

That wouldn't make just sense to me since all the timings around this part of the code are in ms/us i.e. not timing sensitive. However, glad you have some sort of a solution. On the latter issue, if you're using XS2 be sure to disconnect the usb phy from the bus rather than just rebooting the tiles (see reboot code in lib_xud). This is straying into custom code modifications now and doesn't look to be an issue with lib_xud so closing.

[susnak]

Just leaving this here as a solution, which is indeed not lib_xud related. As @xross mentioned,

XS2 be sure to disconnect the usb phy from the bus

this turns out to be the culprit. This is missing in UAC2 6.15.2 and was patched in UAC2 7.2.0