USB and internal xlinks failing over time

[CousinItt]

Ed, can you clarify your remarks on X2D67, 68, 69, 70? I can see constraints for X2D07 etc. (presumably for unused boot pin circuitry) but not for X2D67 etc.

[Machdisk]

I do not cycle power when reflashing the IP and it can still fail even when all the power rails are sitting steady at operating levels. Running the circuit from a 5V or 12V medical grade supply I have available for testing makes no difference. I attempted to remove everything from the board except for power, clocks, reset circuit and pull ups and while the USB has not failed yet the first symptom of failure, the inability to transmit data in one direction between tiles on the chip remains. Strengthening all my various ground connections does not appear to have made a difference either.

As for the pull ups on X2D67, 68, 69 and 70. The xmos datasheet doesn't specify anything for those pins but my design should have had pull downs there (They are inputs that detect a button press that pulls them high). I changed them to the pull ups at the same time I adjusted the X2d06 etc ones and the board started working with them on there, I would assume not relevant but little about this makes sense so I thought I would mention it anyway.

[akp]

It would also be interesting to power all rails from linear regs and a bench supply in case the power supply is the culprit. When you say "Replacing a BGA results in the new BGA failing shortly." does that mean it works for a while and then fails? Oh, and you may have mentioned but are you running your own firmware or XMOS firmware e.g. the usb audio ref design or something?

[mon2]

Can you stress test this widget WITHOUT using USB? Really want to isolated the design to the bare minimum BOM. Still transfer data across the links but interested to know if the transfers halt (without using USB)? Has XMOS confirmed that this is not a silicon / factory production fault?