Hi,
We designed a prototype for a 32-channel (16x I2S) USB 2.0 audio interface on small daughterboard PCB. The design is largely based on the XMOS multichannel reference board. That reference board still uses the XS1-L02A chip. Our design uses the XS1-L16A-128-QF124.
The schematics were captured a while back and based on the XS1-L16A datasheet issued 2013/09/16. This document advises to tie al PCU_xxx pins to GND (this involves pins B2, B4, B5, B6). However, more recent datasheets have re-introduced the PCU_xxx pins and contain specific instructions about which pins must be left floating, connected to VDD(IO) or the system clock.
The problem we're seeing on all of our protoboards is that the XMOS controller doesn't respond to the master reset RST_N (pin B8). We can download and run firmware via the XTAG dongle (for which we included an XSYS connector on a base board that holds this XMOS daughterboard), but pulling the RST_N line low on the controller does not make it do a reset. All other I/O, including the interface to the USB PHY appears to work fine though.
We assume that the RST_N input is asynchronous and operates independent of how the PCU-pins are connected. The master reset line in our design is a combination of a local (supply monitor) reset and an external one (controlled by a master microcontroller). This local reset circuitry has an open drain output so RST_N can be shared by the XTAG dongle (see attached schematic excerpt). Please note that our schematic does not number the XS1-L16A pins as A1-A68 and B1-B56, but simply numbers from 1-126. This means the RST_N input is on pin #76.
The first thing we noticed during testing is that the RST_N line is NOT pulled up to 3.3V by the U6 internal pullup, suggesting a bad connection (adding an extra 10k pullup solves the floating RST_N line, but the XMOS chip still won't reset). Because this problem is repeated on all protoboards, we also became suspicious of the PCU_xxx pins.
Q1: Could tying the PCU_xxx pins to GND (as per older datasheet) render the RST_N input useless?
Q2: Doing a JTAG boundary scan continuity test on the chip seems not possible seeing as there is no entry in the BSDL file for the RST_N input. Or are we missing something? (perhaps some XMOS tool we're not aware off could offer more insight).
Q3: what should we do with the PCU_xxx pins on the prototype board? Can we leave them connected to GND, should we temporary cut GND connections and leave them floating or *must* these pins always be connected to the advised supplies and clock for the chip to function properly? The final design will connect the PCU-pins up the right way, but for now we would like to find a workaround that can be implemented quickly.
Thanks for your help and advise in advance.
XS1-L16 Master reset / PCU problem
-
Scrat
- Newbie
- Posts: 1
- Joined: Wed Oct 01, 2014 11:15 am
XS1-L16 Master reset / PCU problem
You do not have the required permissions to view the files attached to this post.
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Some ideas to check:
1) Onsemi NCP1532 datasheet recommends a 500k PU on the #POR line. Perhaps worth testing (although likely not the issue).
2) What is the logic level on the #POR after boot ? Is it pulled high as it should to denote the power is good / stable ?
3) What is the output of the single AND gate (U17) ?
4) U17 and the following open drain buffers are being powered ok with the proper voltage rails ?
5) If you manually pull down RST_IN_N, does the output of the AND gate follow to be a LOW ? Do the open drain buffers also follow to be a low with the same manual pull-down event ? If not, consider to remove the D14 or R72 to break the led circuit temporarily to debug and confirm the open drain buffer follows the activity applied to the single AND gate.
6) Are you using an external flash device to hold your firmware ? Wired as per the XMOS ref design / recommended hardware check list ?
This document advises to tie al PCU_xxx pins to GND (this involves pins B2, B4, B5, B6)
7) B4 on L2 is VDDIO on the ref design = +3.3 volts. Not ground.
8) B5 on L2 is VDD on the ref design = +1.0 volts. Not ground.
9) B6 on L2 is CLK on the ref design = CLK_13M clock source. Not ground.
10) C15 is the analog voltage rail (PLL_AVDD). Ref notes from XMOS note to use 100 nf ceramic = 0.1 uf (not 1 uf). Consider to use X5R or X7R dielectric (NEVER Y5V).
reference:
http://www.justradios.com/uFnFpF.html
11) The XMOS ref design (USB Audio 2.0 MC) features R46 (4K7 = 4.7k) pull-down on RST_N. Perhaps consider to do the same for at least testing purposes. CORRECTION / UPDATE - This recommendation will not be logical to follow since the RST_N is an active LOW signal driven by open drain buffers. Not sure why it is present in the original ref design since a voltage divider will be created (with this 4.7k as a pull-down and IF the open drain drivers is having a pull-up; next issue is that the same RST_N will be always be held low). Best to avoid this suggestion at this time.
12) Another interesting observation is that the XMOS ref design does not feature external pull-up resistors on the open drain buffers (SRST_N & TRST_N) lines.
1) Onsemi NCP1532 datasheet recommends a 500k PU on the #POR line. Perhaps worth testing (although likely not the issue).
2) What is the logic level on the #POR after boot ? Is it pulled high as it should to denote the power is good / stable ?
3) What is the output of the single AND gate (U17) ?
4) U17 and the following open drain buffers are being powered ok with the proper voltage rails ?
5) If you manually pull down RST_IN_N, does the output of the AND gate follow to be a LOW ? Do the open drain buffers also follow to be a low with the same manual pull-down event ? If not, consider to remove the D14 or R72 to break the led circuit temporarily to debug and confirm the open drain buffer follows the activity applied to the single AND gate.
6) Are you using an external flash device to hold your firmware ? Wired as per the XMOS ref design / recommended hardware check list ?
This document advises to tie al PCU_xxx pins to GND (this involves pins B2, B4, B5, B6)
7) B4 on L2 is VDDIO on the ref design = +3.3 volts. Not ground.
8) B5 on L2 is VDD on the ref design = +1.0 volts. Not ground.
9) B6 on L2 is CLK on the ref design = CLK_13M clock source. Not ground.
10) C15 is the analog voltage rail (PLL_AVDD). Ref notes from XMOS note to use 100 nf ceramic = 0.1 uf (not 1 uf). Consider to use X5R or X7R dielectric (NEVER Y5V).
reference:
http://www.justradios.com/uFnFpF.html
11) The XMOS ref design (USB Audio 2.0 MC) features R46 (4K7 = 4.7k) pull-down on RST_N. Perhaps consider to do the same for at least testing purposes. CORRECTION / UPDATE - This recommendation will not be logical to follow since the RST_N is an active LOW signal driven by open drain buffers. Not sure why it is present in the original ref design since a voltage divider will be created (with this 4.7k as a pull-down and IF the open drain drivers is having a pull-up; next issue is that the same RST_N will be always be held low). Best to avoid this suggestion at this time.
12) Another interesting observation is that the XMOS ref design does not feature external pull-up resistors on the open drain buffers (SRST_N & TRST_N) lines.
-
Redeye
- XCore Addict
- Posts: 131
- Joined: Wed Aug 03, 2011 9:13 am
I feel your pain on this one. I wasted days trying to find exactly the same problem before I figured it out.
The problem is the PCU pins. The datasheet which said you should tie these to ground was completely wrong. The original datasheet was correct - those pins need connecting to +3v3, +1v0, CLK as it specifies on the current datasheet. If you don't do that, the device will not reset.
It took me a long time to figure it out, and fortunately I was using a 128pin L8 device so I could just about modify the board. As soon as I connected the PCU pins correctly the device worked perfectly. Obviously I then sent a pretty irate support ticket to XMOS which is when the datasheets were corrected.
I hope you can get to those pins to change the connections, otherwise I fear those boards may be scrap. I'm still pretty furious about this to be honest - after all the time and money wasted on boards I had to scrap in finding the datasheet error all I got from XMOS in reply was "oh, we've changed the datasheets now". It's absolutely inexcusable to change a datasheet to instruct customers to connect pins in a configuration which will never work. Why it was done I don't know but I suspect you're not the only person who's a victim of this mistake.
The problem is the PCU pins. The datasheet which said you should tie these to ground was completely wrong. The original datasheet was correct - those pins need connecting to +3v3, +1v0, CLK as it specifies on the current datasheet. If you don't do that, the device will not reset.
It took me a long time to figure it out, and fortunately I was using a 128pin L8 device so I could just about modify the board. As soon as I connected the PCU pins correctly the device worked perfectly. Obviously I then sent a pretty irate support ticket to XMOS which is when the datasheets were corrected.
I hope you can get to those pins to change the connections, otherwise I fear those boards may be scrap. I'm still pretty furious about this to be honest - after all the time and money wasted on boards I had to scrap in finding the datasheet error all I got from XMOS in reply was "oh, we've changed the datasheets now". It's absolutely inexcusable to change a datasheet to instruct customers to connect pins in a configuration which will never work. Why it was done I don't know but I suspect you're not the only person who's a victim of this mistake.