Help Debugging USB Audio Code on Custom Board

[paul]

Hi,

Are you just using the binary from the website or are you changing the appropriate #defines to configure for your board? If you are just using the binary this most likely won't work.

As for older versions try clicking "View all versions" under the appropriate entry in your xmos account - https://www.xmos.com/user

Regards,

[GeorgeIoak]

For now I'm using the compiled code because our design follows the reference design. We're using a DAC instead of the CODEC but since the reference design puts the CODEC in slave mode and we do the same with our DAC then just seeing data on SDIN when music plays should be the same.

I'm using the USB3318 and have followed the same pinout assignments. I'm also using the same clock scheme so from what I'm looking at I should be seeing a signal. I have confirmed that I do get LRCLK, SCLK, MCLK, and while in debug I have seen SDIN for 30-45ms before the code stops.

I could still have a hardware problem but my gut tells me that somehow the firmware is looking for something that it's not seeing in our design and shutting down but for the life of me I don't know what.

I went through all the power up sequences and confirmed things are coming up as specified and I've also confirmed that when the code stops it is NOT because of a reset signal being asserted.

I've attached some additional debug data that I took last night if someone sees something odd let me know.

[bearcat]

I logged into my account yesterday and had tried the other versions link to see what was there.
I only got the latest version listed and only version 2 was shown as a link under my account.
Maybe not as intended?

[GeorgeIoak]

That's all I see there as well. Does anyone by chance have a copy of the older code?

[GeorgeIoak]

Have any of you used any other EEPROMs besides the Atmel one that is used on the reference design? I'm using a Winbond W25X10BV and XMOS provided the attached spi-spec file but looking at I wonder if there is a typo because it starts with "8," and looking at the end of the customdefines.h at DFU_CUSTOM_FLASH_DEVICE that structure looks different.

Am I suppose to #define DFU_CUSTOM_FLASH_DEVICE and then modify the structure to match what XMOS provided?

I've been using the --spi-spec "W25X10.txt" on the erase and program lines but shouldn't the actual firmware need to change to be able to read from the EEPROM properly since it seems the definitions are different??

[bearcat]

In my opinion:

Yes you define DFU_CUSTOM_FLASH_DEVICE. Then replace the DFU_FLASH_DEVICE in the firmware with the copy you were given. Yes, the 8 appears to be extra information that should be removed.

I have not tried a custom Flash chip yet. I have not tried the DFU yet either. Any comments on DFU would be welcome by myselft, at least.

[GeorgeIoak]

I've got DFU compiled in but right now I'm testing on a MAC which doesn't use the DFU. I cleaned up my boards and got the power rails dialed in so everything is clean as a whistle now.

I got some limited success yesterday seeing data on SDIN and today I recompiled and commented out the #define SPDIF statement and running in debug mode I have my board running for over 1 hour. I don't see SPDIF_RX defined anywhere so we're strictly talking about SPDIF transmit. Since that pin comes straight out of the L1 and into a F/F and we're using the exact same part (NC7SZ175) I can't see how hardware could be an issue here.

So the question is, why does the code stop when SPDIF_TX is enabled??

I've attached another detailed console output in case one of you experts can see something.

[GeorgeIoak]

Can someone help me to determine where in the code I can add some "print" statements that will output to the console window so I can try to determine why the code is stopping? I completely new to XMOS programming and am not a programmer by nature so any helpful push in the right direction would be greatly appreciated!

[lilltroll]

So the question is, why does the code stop when SPDIF_TX is enabled??

I guess I could find the answer in your dumps, but;
http://www.xmos.com//system/files/xmos- ... de_2v0.pdf chapter 9,
Since release 2.00:
"The XUD library requires an 80MIPS thread to function correctly (i.e. on a 500Mhz
parts only 6 threads can run)."

How many threads do you use?

[GeorgeIoak]

I have not modified the audio reference design source code except for recently trying to disable functions to narrow down the problem.