Migrating from XHRA to XU208

[mon2]

Please confirm that you had a strong pull-up (1k was used by the XMOS XHRA ref design) on the CS of the flash device.



Just in case the CS pin on the XMOS device and related IP is making this pin behave as open drain (OD). Ran into this issue with Cypress last week for an undocumented port pin. That is, the external pull-up was mandatory to see a logic high.

Confirm again that the power rails are stable. Perhaps the XU208 consumes more current than the original XHRA processor?

Silabs clock generator (PLL) is ok for at least the required 24M line?

CPU swap is clean and no shorts for the replacement? If practical, consider to review with an X-RAY system.

The ADUM1085 is an open-drain reset supervisor. Does the output of this supervisor go high ok? Would not hurt to apply an external pull-up if you do not have in for this circuit. Believe that the XMOS device has an internal pull-up for the RST_N pin but again, will not hurt to apply one to be sure the CPU is released from reset.

XU208 devices sourced from an authorized supplier? Digikey / Future Electronics are ones that we know of are ok. To be sure you are dealing with remarked empty packages.

Perhaps you have already tested this but if you remove the external flash device off your PCB - then do you see the CS pin of the XMOS (SPI master) / flash device toggle?

also

The XU208 features a metal belly pad which could be fun to solder. Confident that this required metal belly is soldered? This is a ground pin to the device. This missing pad could be a root cause of the non-working boards.

Any chance you have bonded out the test points (TP) to match the original XHRA PCB? If yes, then you could wire up to an external XTAG3 tool to further debug if the XU208 CPU is alive and functional on the custom PCB. See pins 60..63.

[jmag99]

Yes, we have a 1K pull-up on the chip select (same as the reference design).
Power rails are stable and are the same chips as the HPA reference design (which is supposed to work with this chip according to this thread).
CPU swap is clean, verified in 2 offices on 2 different boards using microscopes.
Supervisor does go high. There is an external pull-up (same as the reference design).
We are using a 24MHz oscillator, not the silabs part, but we have used this same part with literally thousands of xmos parts.
XMOS chips came from Digikey.
I did isolate the xmos from the spi flash to verify that chip select was being held low by the XMOS.

Thanks for the help, i appreciate you sticking with it. Hopefully someone from XMOS can confirm that this chip was actually tested on the HPA reference design.

[mon2]

If we have followed this thread correctly, believe that:

a) the exact firmware from the original XRHA design will not boot as-is on the XU208 CPU. You will have to follow the procedure outlined at the start of this thread to target the XU208 CPU. Also, from memory thought that the original contents of the XRHA firmware was encrypted so will fail to load if applied as-is. That is our understanding.

b) the CS on the flash is ACTIVE LOW. If LOW, the flash is being enabled by the master. Do you see any activity on the other flash pins? For example, SPI CLK pin 6? Are you monitoring the CS pin with a logic analyzer? If not, the true activity of the CS could be missed. Please do review the logs that have been posted by ISSI when the XRHA board was reviewed by their side. In their logs, the CS pin shows activity but keeping in mind that the XRHA CPU featured factory ROM code inside. The review was to confirm why any brand of flash will not work. Summary: The ROM code inside the XRHA device is checking for the flash IDs.

If the XMOS CPU is configured for QSPI Master boot mode then the external flash must be also in QSPI enabled mode to spew out the data, 4 bits at a time. Our thoughts are that if the firmware from the XHRA widget are applied to your custom PCB with the XU208, as-is, then the XRHA firmware will not load correctly. Guessing that the XHRA had the internal OTP ROM code to decrypt the firmware during boot time. Your product does not feature this ROM code for decryption so cannot be used as-is.

Guessing that your XU208 may be booting but locking up due to the encrypted code intended for the XRHA target.

A suggestion is to code up a simple GPIO blinky firmware to load into the external flash. This is to only validate that the custom PCB is able to boot your simple firmware to blink a port pin, etc. You could whip up this code and validate on an XCORE-200 Explorer kit or similar and then place onto your custom PCB for testing. Like your XU208, the XCORE-200 Explorer kit also demands that the flash device be in QSPI mode (bit for the flash must be enabled). The focus at this time is to validate that the XU208 is able to boot any code using a simple external flash firmware while the external flash is in QSPI mode. Once a simple LED blinky code routine is operational and stable then proceed to compile the audio source code as per the first post in this thread.

[DHembree]

- Copy over the top of a fresh 6.15.1rc2 (latest released version) reference design download. Note you will need to copy into the root of the reference design project so that the sw_usb_audio and sc_usb_audio subdirectories are correctly overlaid. Download from here https://www.xmos.com/support/software/uac2

Can someone clarify this for me?

Should I extract a fresh copy of sw_usb_audio-[sw]_6.15.2rc1 into the workspace folder, then extract xhra2xu208_1v0 and copy the two directories it contains into and over the workspace files/folders? It appears there are several files and folders within the original module_usb_audio subdirectory that will be deleted and replaced with only the few files in the new module-usb_audio, such as .cproject, .makefile, .project, and a few others.

This is all new to me.

Thanks in advance,

Dan

[mon2]

Hi Dan. Received your private email ping. Had to cook dinner and now energized :)

Not an audio developer but understand this as follows:

1) Download the source code :) package linked in the first post for the XRHA design. Extract this download to a local folder. There are 2 sub-folders inside this download.

2) Download the source code package for the 6.15.1rc2 (latest release version as of this writing). We created a new project as used the XU208 device (same memory & TQFP64).

3) Import into this project using .zip package -> point to the .zip package for the 6.15.1rc2 -> this package offers many sub-folders. 2 of the sub-folders are of the same name as the XRHA design.

4) Locate the folder with your new audio project for this exercise and enter the root folder to locate all of the expanded folders from 6.15.1rc2. Now copy and paste the 2 extracted folders from the XRHA folder. You will be replacing the older 2 folders with the new version.




(attempting to document this better but need some time with many more screen shots)

5) Then go back to xtimecomposer and select File -> Refresh. Proceed to Project -> Clean -> Build. Be patient as the building project may take 20-30 minutes. My PC has been compiling for the past 10+ minutes and no raised errors - 22% done without errors so far...

You will have to modify and customize as desired and as noted by the first post. Not an audio developer so do not know of the details here. Give it a try and hope this helps. Time permitting, will try to post screen shots of the above procedure asap.

[fabriceo]

Hi
I havent honestly yet deep dived into the I2S Source code and associated documentation, so I may ask a naive question here : for some reason, instead of supply a Master Clock 22/24.576mhz, I might provide directly a BCLK and LRCLK at the proper bit rate (e.g. using a PCM5122 DAC in master mode, which will manage the 2 quartz), which somehow is the same thing as considering the XU208 as a Slave I2S.
is it possible to configure the USB Audio framework as slave i2S in the definition files, or at least is it possible to tweak the code with relatively low headick ? do I still need an MCLK pin on the xu ports or I could release this 1bit port for other usage?
I ve just received an xtag3 and will play soon with all of this :)

thanks in advance for your support.

[mon2]

http://www.xcore.com/viewtopic.php?f=37&t=5870

http://www.xcore.com/viewtopic.php?f=26&t=4963

[DHembree]

Mon2,
I have tried to follow the instructions you sent, but I am not having any luck. Below are some screenshots showing the steps I took:

Creating new Project:


Project created:


Importing 6.15.2rc1:


XIP (archive) selected:


Post import results - note: no sc_usb_audio or sw_usb_audio


Not sure what I'm doing wrong. Help!

Dan

[mon2]

Happy Tuesday Dan :)

In the zip folder screen - scroll down and you should see the 2 folders with names of

sc_USB_audio
sw_USB_audio

Please confirm this.

Then download the source code you downloaded from the original poster, first post in this thread. Inside this zip fileset are folders with the same name as the folders above. Copy the contents of these new folders and extract to the above folders with the same name.

Then proceed to compile.

[mon2]

Hello. Just merged the new folders over the older and the final package is attached here. Give this a try. Again, not an audio developer but believe this is the final package that should at least compile and then proceed to tweak to suit your custom product. Please post your result and do let me know if it does not work.

---

OMG - the attachment feature is still limited to 2MB -Urghhhh. Let us post onto our company server...

https://axxonshare.s3.amazonaws.com/xmo ... 5.2rc1.zip