XHRA-2HPA No USB Activity Topic is solved

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
DHembree
Experienced Member
Posts: 75
Joined: Fri Apr 15, 2016 6:46 pm

Post by DHembree »

Mon2, Thanks for the reply!!!! I have been within inches of abandoning this part for lack of response and near zero support directly from XMOS. Baffling.

I had previously read the thread you suggested but failed to see the PDF of the working transaction between device and flash. This is precisely what I was hoping for. There is no description in the data sheet as to what to expect from this interaction between device and flash. I will compare the image with what I have.

I do not have a golden pre-programmed flash. I inquired with XMOS about obtaining one, but they only referred me to the digi-key site to purchase an eval board. Is there a source for flash chips with the firmware programmed??

Thanks again,
Dan


View Solution
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi Dan. XMOS has a great product line and fairly stable tools but support I think is focused more towards the larger OEMs for their roi. Also believe XMOS is a bit short staffed. We have been reviewing the line for a while now and hope to pull assorted triggers for a number of unique designs but in short, we feel your pain. The devices are not quite as simple as expected to understand on first reading of the related documentation.

We have the referenced XHRA-2HPA board but is offsite with another engineer. Let me ask if the engineer can release the board so we can clone the flash device. One of the projects on my wish list is to offer a simple tool to do just that, use the StartKit to flash program the target blank QSPI flash and enable the QSPI feature. We invested a great deal of time in learning all about standard SPI use and also the assorted QPSI transactions and wish to target a project before we forget this wealth of knowledge.

In summary, you need a tool to program the blank QSPI flash device - first out of circuit & enable the QSPI bit -> then solder onto a PCB with this controller. There are many approaches to such a solution but in the end, it is all simple bit-banging and could easily be applied using the StartKit. The premise would be to park (aka tri-state) (hold @ reset for example should work) the XMOS CPU that is present on such audio projects so that the IO pins do not interfere with the QSPI line sharing -> inject your code and then you are off to the races.

Do you have a tool to program the respective QSPI flash memory ? What is your time line ?

Where are you located ? You can send me a private email with your location details, if you wish.

Also, the QSPI devices come in many shapes and sizes (widths, etc.) - which are you using ? Share the specific device info on your flash component.

Salivating at assorted ideas on how to conquer this programming exercise which appears to be surfacing repeatedly with this project.
just280
Member++
Posts: 22
Joined: Tue Nov 01, 2016 9:02 am

Post by just280 »

I understand now, thank you.
DHembree
Experienced Member
Posts: 75
Joined: Fri Apr 15, 2016 6:46 pm

Post by DHembree »

Mon2,
I would have moved on to another solution if I hadn't been convinced of the part's performance based on the presence of the XMOS technology in so many quality commercial solutions.

I understand the support level based on ROI. My project is for client who is an OEM. I'm a hired gun so I don't pry too much into what his EAU's will be, but have to assume that there is something there.

My design is heavily influenced by the eval board design. My initial board excluded the QSPI flash as I had intended on configuring via strapping and was unclear as to the necessity of the presence of flash/firmware. I did a subsequent design that incorporated the flash via a DIP socket/SOIC-DIP carrier board so I could remove the flash and program externally. I have a ZIF-socketed programming tool that supports the Spansion (Cypress) S25FL116K0XMFI040. This is where it gets a little sideways - the programming tool interface does not appear to have the ability to program with the LSN/MSN reversed in order so I had a colleague develop a small application to reverse the order of the nibbles within the original bin file. I then program the flash with this modified bin file, enabling the quad mode bit in the process. As I have mentioned in previous posts, I see what appears to be meaningful data on all four data lines, just no activity on the USB bus. This is where having a "golden" flash device to replicate as needed would be invaluable.

I am in the Nashville, TN area.

I am deeply appreciative for your help!!!

Dan
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi Dan. So to confirm,

your S25FL116K0XMFI040 (Spansion / Cypress, whatever) is a standard 150 mil, SO8 package ?

That helps in debugging as we are using this footprint and fairly sure that XMOS is using the same package on their evalboard. Hope to know more after our engineer with this board chimes in to see if he can part with the official XMOS board. We are working on some 'ultimate XMOS audio' based design as well. He is probably out raiding the local stores for the 50-75% discounted Halloween candies.

The goal here is to take one of our blank QSPI flash memories -> clone the official XMOS QSPI contents with QSPI enabled -> solder back onto the official XMOS PCB to confirm the adapter dongle continues to function as supplied by the factory (with the USB activity).

Aside from the QSPI flash contents, have you confirmed the observation to be the same on more than a single PCB ? Perhaps the USB lines are ESD damaged so test another assembled board ?

Do you have USB bus analyzer ? Technically should not be required but would help.

We are preachers for ESD protection and use SOCAY (Shenzhen, China) for our designs. Very affordable, low MOQ and short lead times. Met them again a few weeks ago in Hong Kong at the electronics fair. They have drop in replacements for all the 'brand names' and may very well be the true manufacturer for these larger firms (ie. Semtech, Bourns, Littlefuse, etc.). Highly recommend ESD protection on your USB lines if you do not have this already. Met some amazing alum enclosure companies who are producing for the very large audio / computer companies - they are not shy in advertising their names at these fairs :)

Have you posted a schematic of your design here in this thread ? (or partial for review)
DHembree
Experienced Member
Posts: 75
Joined: Fri Apr 15, 2016 6:46 pm

Post by DHembree »

Yes, I'm using the standard SO8 package soldered to a carrier board to adapt to DIP for easy/multiple removal, and a more robust connection in the programmer's ZIF. The SO8 adapter they provided was questionable.

While I have additional PCBs of the later version, I have not assembled another. Admittedly, there is no ESD protection on these prototype boards, but suspected that might be an issue and took precautions during assembly.

What is your take on the nibble reversing?

I would love to get my hands on a golden child flash if you'd be willing...

Schematic is attached.

Dan
Attachments
MT USB-I2S Bridge.pdf
(159.1 KiB) Downloaded 440 times
MT USB-I2S Bridge.pdf
(159.1 KiB) Downloaded 440 times
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

I would love to get my hands on a golden child flash if you'd be willing...

Working on that once our guy chimes in and is willing to part with the board. More details to follow on this.

Great on the schematic post. ESD protection is a must. General flow is to protect the Vbus from overshoots although your LDO should survive most surges with limit; be low capacitance so the D+ / D- lines do not get tanked down.

The part we have in our designs is SOCAY ULC0524P with a flow through pinout. So pin 1 is to short to pin 10 on the PCB pads; pin 2 with pin 9, etc. This part is ultra low capacitance and can support USB 3.1 Gen 1 so no issue to support this XMOS controller and USB LS / HS.

This part in 3k MOQ is $0.042 USD (F.O.B. Shenzhen).

w.r.t your schematic, a few comments

- the Analog ADM1085 is open drain so there is no defined logic high. Unless there is a pull-up inside the XMOS RST line, recommend to apply a 10k or similar (value is not critical) to Vcc (3v3) onto pin 4 of the ADM1085.

- R29 in your schematic is 3k24 and should be 3k9 (XMOS original design)

- concerned about the LDO regulators and the required power sequencing for the 3v3 and 1v0 rails before the RST line is to be released on the XMOS CPU. The 3v3 rail should be stable first, then enable the 1v0 rail and when the 1v0 rail is deemed to be stable, release the RST line on the XMOS CPU to reset. Being an OD output, the pull-up on the ADM1085 is a must. However, you should seek out a 3v3 LDO with a power good signal which will drive the EN on the ADM1085. The PG signal is high (usually through an OD with a pull-up) typically when the power rail is around 80% of the LDO rated value. As it is shown in the posted schematic, by tying the EN pin directly to 3v3, the enable on the ADM1085 could trigger much earlier during the LDO ramp up time.

- moving forward, when the 3v3 rail is stable (ie. local PG on this LDO goes high) - only then enable the 1v0 rail through the next LDO. Then when the 1v0 rail is stable, only then the ADM1085 releases the RST line (but is missing the required pull-up resistor to 3v3).

- will you be using the usual Si5351A PLL ? There is a XMOS initiated version of this PLL available through Digikey and perhaps other distributors which will be factory programmed so that you will have the required factory clocks immediately upon power up. Then I2C can be used to alter the PLL values on demand. Best to source the XMOS recommended part (Si5351A-B04486-GT) by SiLabs. Great little PLL !!

Try again with a pull-up to 3v3 on the RST line and post your results but if still not working, the required power supply sequencing is worth a deeper review.

Will chime back once our engineer does the same on the flash device.

====

I2C pull-ups R11 & R12 are quite strong @ 1K. While not the show stopper here, recommend to increase to 2k2 or even higher 4k7.

====

S1 is for a manual PB to reset the XMOS device but is mechanical. Being mechanical, the contacts will bounce a great deal before settling and lead to chaos on the RST line. There are low cost ICs that will take the mechanical PB and convert to a clean text book square wave output. You will need such a device for best results here with an OD output so you can tie the OD output from the ADM1085 and this pending PB IC. Believe we have seen voltage supervisors WITH mechanical PB support in single device. If I can locate the details, will post back later. Summary: the mechanical PB must be debounced to properly reset the XMOS CPU. BTW - met with some great PB manufacturers in HK - you will want a component that can be machine washed (ie. IP67 and is sealed) - many vendors do not allow for this after PCB assembly.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Dan - how did you make out with the raised ideas ?

We now have the official XMOS audio board (XHRA-2HPA) on hand and just confirmed the unit docks fine with their 64 bit Windows driver on my Win7 box.

Do you own any XMOS dev boards ? Perhaps XMOS StartKit or similar ?

How did you program the QSPI flash memory device for your target custom board ?

Even though you are working with a QSPI flash memory device, the industry standard SPI flash memory commands are suitable to R/W/E the target memory (including enabling / disabling of the QSPI mode bit). Being single bit access, the procedure to R/W will be much slower than the use of the wider QSPI interface.

If you are still not observing USB activity after the rework, recommend to have you post the binary image of your firmware for a review.

You should also be able to obtain the raw image from this download to compare against your image:

https://www.xmos.com/download/accept/xC ... rc1%29.zip
DHembree
Experienced Member
Posts: 75
Joined: Fri Apr 15, 2016 6:46 pm

Post by DHembree »

Mon2,

Thanks for all the input, it is greatly appreciated!

I'm working on this as we write. I have decided to address the power sequence and reset issues with a new board revision, so I have nothing to post quite yet. I found a voltage supervisor with a manual reset input to debounce the mechanical switch. I knew this would be a potential issue when I dropped that switch in the original circuit, but figured I would get a clean reset at least some of the time.

I have added a voltage detector to monitor the 3V3 rail and produce a power good signal that enables the 1V0 regulator and ADM1085. I added a 4.7K pullup on the ADM1085 OD output, though I believe there is an internal PU on the RST_N pin of the XHRA. I think I should be able to get a proper power sequence with this scheme.

I do not have any XMOS devel/eval boards. The client has been a bit sluggish with remittance so I have been trying to keep my expenses to a minimum.

QSPI flash memory was programmed with a TL866 universal programmer. The Spansion flash is mounted to an SO8-DIP carrier so I can remove it from the target and program out of circuit. The user interface of the programmer does not appear to have LSN/MSN flexibility. Not an expensive programming tool. Did I mention the client is slow to pay?

I have the latest binary file and ran it through the nibble swapping routine I have prior to programming to flash. Scanning through the buffer after a read looks good, though I don't know if there is any information in the original binary that needed to not be swapped. I will post the file. Not proud anymore.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Dan, the XHRA-2HPA indeed appears to have a 35k PU on the RST pin so believe you are ok with the OD pin not having a PU. The use of the PU on the demo board now appears to be redundant. Recommend that you consider to insert the footprint (0402 size is quite popular and cheap) but do not stuff during assembly. That is, use an external PU on RST only if you must.

Noting the above, how did your enable the QSPI bit inside the SPI flash memory device ?

Does your external flash programmer offer a specific feature to enable QUAD mode ? This will be a standard SPI serial command but must be supported. Without this bit enabled, the firmware you have written into the QSPI IC will NOT function. Checking with other developers on which exact firmware from XMOS (ie. swap nibbles or use as-is) is to be used for production.

Silly part is that the XMOS firmware could have easily written the same QUAD enable mode bit in their boot ROM.

Also, time permitting, will confirm the same in the lab by dumping the supplied QSPI flash memory from the ref board.

When you are ready, post your latest schematic for a review before moving to build another board.
Post Reply