Cannot connect to device (XEF216)

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
MyDirtIsRed
Junior Member
Posts: 5
Joined: Wed Sep 12, 2018 7:36 pm

Cannot connect to device (XEF216)

Postby MyDirtIsRed » Wed Sep 12, 2018 7:59 pm

Hello,

I have a new custom PCB with an XEF216-512-FB236-C20 on it. I'm trying to bring up the board, but I cannot connect to the part. When I run 'xrun --jtag-speed 10 -l', I get:

Code: Select all

Available XMOS Devices
----------------------

  ID   Name         Adapter ID   Devices
  --   ----         ----------   -------
  0    XMOS XTAG-3            7xQNacvX   None



Attaching other dev boards such as the XK-1A and xCore eXplorer boards return the correct thing, e.g.

Code: Select all

Available XMOS Devices
----------------------

  ID   Name         Adapter ID   Devices
  --   ----         ----------   -------
  0    XMOS XTAG-3            7xQNacvX   O[0]



I figured the worst-case scenario, that there is some kind of design issue. However, when I scope the various JTAG signals, I get what appear to be healthy and consistent signals. However, I have no idea what the values mean. Below is a scope captures which illustrates what I'm talking about (Magenta is TDO, Blue is TCK).

20180912_tdo_tck.png
(50.77 KiB) Not downloaded yet
20180912_tdo_tck.png
(50.77 KiB) Not downloaded yet


I think I worked out that the bytes come back as:

Byte0: 0x00
(pause)
Byte1: 0x19
Byte2: 0x8D
Byte3: 0x40
Byte4: 0x00
Byte5: 0x0F

All bits afterwards are 1's. Any insight into what could be happening would be appreciated. I'm kind of at a hard stop until I can figure out what's going on.

Thanks,
Jake
User avatar
mon2
XCore Legend
Posts: 1285
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Sep 13, 2018 10:05 am

Hi. Could be one of many issues. Please post this relevant cpu, power sequence, power supply and xtag3 schematic of this design in pdf format if possible. Was a reliable contract manufacturer used to assemble this board? Does another pcb behave the same?

Ps: hate the auto word fill feature on this tablet!!


Also, go through this checklist for a possible resolution.

xtag_xmos.png
(106.55 KiB) Not downloaded yet
xtag_xmos.png
(106.55 KiB) Not downloaded yet
MyDirtIsRed
Junior Member
Posts: 5
Joined: Wed Sep 12, 2018 7:36 pm

Postby MyDirtIsRed » Thu Sep 13, 2018 7:30 pm

mon2 wrote:Hi. Could be one of many issues. Please post this relevant cpu, power sequence, power supply and xtag3 schematic of this design in pdf format if possible. Was a reliable contract manufacturer used to assemble this board? Does another pcb behave the same?


CPU: XEF216-512-FB236-C20
Power Sequence: See the attached scope plot. To summarize: VDDIO/OTP (3.3V), CORE/PLL (through a filter) comes up ~440us later, monotonically and within 1ms. Supply values are within spec.
20180913_SupplyRamp.png
(57.55 KiB) Not downloaded yet
20180913_SupplyRamp.png
(57.55 KiB) Not downloaded yet

I will attach schematics of the relevant circuits here:
20180913_Schematics.zip
(1.24 MiB) Downloaded 31 times
20180913_Schematics.zip
(1.24 MiB) Downloaded 31 times


Not sure what you mean re: XTAG3 schematic. The board has an edge connector on it, where the board itself plugs directly into a socket. I then run jumper wires that I soldered to the XMOS XTAG3 board to the PCB that also has the socket. The layout of the test signals themselves probably needs to be revised when we do the next board run, but once I slow the interface down (--jtag-speed 10), when I probe the signals, they look good to me.
Sierra Circuits did the boards. We've used them frequently in the past with good results every time. These boards look very good as well. I looked at the XMOS under the microscope, and there's no visible 'potato-chipping', and the balls that I can see on the perimeter all look to have good adherence and compression. I haven't asked if they were X-ray'ed yet, but I think that is part of their outgoing inspection process.

I've only tested two PCBs to this point. The outward behavior is the same, but I have not probed both thoroughly (only 1 so far has been probed).

When you review the schematics that I'm attaching, a few things to note:
-The pull-up for U21 is missing from the design, so that required 'blue-wiring' one to the board. The pull-up pulls up to 3.3V in order for its logic level to be compatible with the downstream AND gate which controls the XMOS reset signals. In scoping the board, I realized that one problem with this circuit is that the open-drain transistor on the output is not active until the supply that it is monitoring hits 700mV. Therefore, the reset signal was initially high when the core supply was coming up. This means that whenever the board is given the signal to power-up, the reset signal needs to be held low 'manually'. Even after taking action on this, the aforementioned problem persists.
-R51 turned out to be too big, due to the internal hysteresis of U13. It was replaced with a short. Now the supplies come up as expected.
-L11 and L12 are not 100 mOhm resistors as they appear in the schematic. Instead they are ferrite beads.
-Also, the component is labeled as XLF216-512-FB236, but the XEF part was placed on this board so that we could utilize the ethernet interface at a later time via an expansion connector.

Now, getting to the checklist that you graciously attached (thanks!):
1.) The JTAG interface to the XCore has been disabled in the OTP security register.
If it has, it wasn't by me, as I've yet to be able to connect to the chip in order to manipulate any registers.

2.) The device is being permanently held in reset by the RST_N signal.
Confirmed with a scope that this is not the case.

3.) No clock is being supplied to the device; or the clock frequency supplied to the device is unsuitable for the selected PLL multiplier.
So the SI5351A on the board is behaving a little bit badly, in that the output frequency is not what I programmed (with the register values coming from the ClockBuilder Pro tool supplied by SiLabs). The intended output frequency is 25MHz, but instead the output frequency is 4.5MHz. Luckily, I broke out 0402 footprints for the mode pins so that I could adjust them as necessary in case something went bad. I placed 0-ohm resistors in those spots in order to set the mode to 0b00, which according to the datasheet should be correct for an input frequency of 4.5MHz. Still no luck with my issue.

4.) The VDD core supply is outside of tolerance.
Core supply appears solid. ADP5310 is capable of providing 800mA.

5.) The VDD PLL supply is outside of tolerance.
Filter was taken from reference design.

6.) The power supplies have not been correctly sequenced.
Attached plot shows sequencing is correct, I believe.

7.) The device, especially the ground paddle, has not been correctly soldered to the board.
BGA, so no ground paddle on this part. I can't speak to opens, but there are definitely no supply shorts.

So after some work this morning, I'm still in the same predicament I was yesterday :-(

Any more guidance would be appreciated.

Thanks,
Jake
User avatar
mon2
XCore Legend
Posts: 1285
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Fri Sep 14, 2018 4:49 pm

Hi.

1) Unable to follow the operation of U20 and as to why it is required. If Q3 is OFF, then VDDIO_3v3 is off? U17 is powered from this switched rail so there could be some chaos at play here.

Remove Q3 and bridge pins 1 & 2 of Q3 to allow for VDDIO_3v3 to come up asap.

2) Where is the source of XMOS2_ENABLE signal?

3) What is the value of R45? It should be 43R2 ohms for USB_TUNE pin. The schematic is very grainy so please confirm.

4) Which Si5351A PLL was sourced for this build? Is it the XMOS version or just a blank part? If factory blank and without any OTP factory values, does this PLL power up and immediately supply a clock value. Although JTAG should not require the clock due to TCK, normal operation of the CPU will demand a working clock source upon power up. After the boot of the XMOS IP, the Si5351A clocked XMOS CPU can be an I2C master and alter the PLL to suit. Digikey and Mouser offer the pre-programmed PLL defined by XMOS.

As a test, you could consider to slap on a fixed external 3v3 CMOS 24 Mhz clock oscillator in place of the PLL to remove the doubt off the Si5351A.

Please post your results.
MyDirtIsRed
Junior Member
Posts: 5
Joined: Wed Sep 12, 2018 7:36 pm

Postby MyDirtIsRed » Fri Sep 14, 2018 5:11 pm

First of all, thank you immensely for taking the time to go through the schematics and trying to understand the operation of things. I apologize for the grainy nature; unfortunately, a recent Windoze update broke AD17 printing/PDF'ing, so I wound up taking screenshots instead.

Now, responses:

mon2 wrote:Hi.

1) Unable to follow the operation of U20 and as to why it is required. If Q3 is OFF, then VDDIO_3v3 is off? U17 is powered from this switched rail so there could be some chaos at play here.

Remove Q3 and bridge pins 1 & 2 of Q3 to allow for VDDIO_3v3 to come up asap.

U20 is required in our system due to the presence of some "medium" voltage circuitry elsewhere on the board; it is used to aid correct supply sequencing. I've probed the supplies and the reset signals and they behave as I expect and within the datasheet specifications (after the aforementioned modifications around U21).
mon2 wrote:2) Where is the source of XMOS2_ENABLE signal?

Off-board.
mon2 wrote:3) What is the value of R45? It should be 43R2 ohms for USB_TUNE pin. The schematic is very grainy so please confirm.

Yes, 43R2.
mon2 wrote:4) Which Si5351A PLL was sourced for this build? Is it the XMOS version or just a blank part? If factory blank and without any OTP factory values, does this PLL power up and immediately supply a clock value. Although JTAG should not require the clock due to TCK, normal operation of the CPU will demand a working clock source upon power up. After the boot of the XMOS IP, the Si5351A clocked XMOS CPU can be an I2C master and alter the PLL to suit. Digikey and Mouser offer the pre-programmed PLL defined by XMOS.

As a test, you could consider to slap on a fixed external 3v3 CMOS 24 Mhz clock oscillator in place of the PLL to remove the doubt off the Si5351A.

Please post your results.

Yes, known issue on this board. Blank part, which of course does not output a signal upon power up (stupid behavior, IMO, for a clock chip whose main purpose to clock microprocessors). However, I have I2C available on my edge connector, so I'm able to program the chip and then pull the XMOS out of reset. Clock looks good (i.e., 25MHz). I then depopulate the mode resistors (R18/R19) and rely on the pull-ups internal to the XMOS to set MODE[0:1] to 0b11.

Thank you again,
Jake
User avatar
mon2
XCore Legend
Posts: 1285
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Mon Sep 17, 2018 1:02 pm

Be sure that:

1) for the XTAG wiring that TDO from the XTAG3 tool is to TDO of your target CPU; TDI to TDI and not TDO to TDI, etc.

2) how does the XTAG3 tool behave if mated with the other working XMOS boards? Do you see the same initial stream of output values but the working boards continue to stream out additional data?

What if the XTAG3 tool is not connected to any target board - what is the activity on TDI of the tool? Is this same activity seen when you mate the XTAG3 tool to your target CPU?

3) still concerned about the VDDIO_3v3 voltage and when it is turned on / off relatively to power on. Can you strap that voltage to be ON and do so at the same time as the main VDD (3v3) rail? Concerned that any such delays of this voltage rail may cause internal latch up during power up and this voltage rail could be the power source for the internal boot mode pull-ups. This would cause the PLL registers to see a wrong value and also result in chaos.

4) do consider to have the PCB x-ray inspected to rule out assembly or confirm with the CM that your boards have been properly QC inspected. Although you are noting that the TDO pin is sending out data from the XMOS CPU to the XTAG3 so that is a good starting sign.

5) JTAG / XTAG is a basic interface but a bit concerned about the use of the push pull drivers (74HC08) vs open drain. You could consider to apply 74HC38 in this same location and then wire up external pull-ups to see if the results are any different. From our experience with building an JTAG master (we used XMOS to build a JTAG master to reflash a target Lattice FPGA and the results were excellent). The website, fpga4fun by Jean has some excellent low level details on this topic which we followed during our coding of our StartKit to build this tool. From memory, do not believe there is a MIN TCK requirement but will result in longer user delays when performing simple JTAG tests like reading the device ID, etc.

6) On the Si5351A, for USB use, you will want 24 Mhz but this is not the current root cause of this JTAG fault. From our understanding, this external clock could be DC but if XTAG3 is working correctly (due to TCK being the only required clock for JTAG) then the internal state machine should spew out valid data.

7) XMOS_nDEBUG is required to have a pull-up which you show @ R50 but again, the pull-up rail is the switched VDDIO_3V3. If this rail is delayed and enabled after the XMOS pin is internally sampled then you could be losing out due to a race condition. If possible, mate these group of 3 pull-up resistors to the 3v3_AO rail (ie. the main 3v3 rail). Same for U17 (if possible).
MyDirtIsRed
Junior Member
Posts: 5
Joined: Wed Sep 12, 2018 7:36 pm

Postby MyDirtIsRed » Mon Sep 17, 2018 7:04 pm

Sooo...

A coworker of mine who has much more experience with XMOS chips than I do suggested that I switch over to using an XTAG2 board. He stated that he had seen some 'flakiness' in the past with the XTAG3 board. I was skeptical, since the XTAG3 board that I was using was talking just fine to the multiple development boards that I had hooked it up to. Nevertheless, I connected my custom PCB via an XTAG2 board, and what do you know:

Code: Select all

Available XMOS Devices
----------------------

  ID   Name         Adapter ID   Devices
  --   ----                 ----------           -------
  0    XMOS XTAG-2            BjD9a8dZ           O[0]

Being a bit of an XMOS noob, what are the major differences between the various XTAG boards, and what could be causing the XTAG3 to not work where the XTAG2 does? I still wary of my design as being robust if it can cause problems in communicating with one of these adapters.
User avatar
mon2
XCore Legend
Posts: 1285
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Mon Sep 17, 2018 9:43 pm

You can review this to see if this resolves your quirks:

viewtopic.php?t=3964

On your testing with the XTAG3 tool, what are the details of your PC? Which OS?

Are you using the blue insulator USB ports (ie. USB 3.0 / aka USB 3.1 Gen1) or the black insulator USB ports (USB 2.0)? Where possible, stick to USB 2.0 ports.

When you tested the same XTAG3 tool against XMOS boards, did you use a different PC and OS or the same host?

XTAG3 has some quirks related to at least Windows 7 and is apparently linked to the possible existence of internal USB hub controllers on your motherboard.

See here:

viewtopic.php?t=4766

From your earlier post, it appeared that your XTAG3 tool is able to send out data to force the target board to send back data to the XTAG3 tool over TDO line. That would imply that the XTAG3 tool is operational. However, XTAG2 is EOL so we are left with only the XTAG3 tool. In addition to this, the design is closed source.

Guessing that both JTAG tools need to be placed onto a USB analyzer to review the differences as to why one works while the other does not.
User avatar
mon2
XCore Legend
Posts: 1285
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Mon Sep 17, 2018 9:53 pm

Given that the toolchain can extract the IDs / serial # from the XTAG3 tool, the enumeration of the XTAG3 on your box cannot be the issue. The brain is talking but body may not be.

Probe your XTAG2 tool and compare notes with the XTAG3, do you see similar activity on TCK, TDI, TDO? There are posts on this forum related to XTAG3 tools dying during "normal" use. Perhaps the XTAG3 interface pins that interface with your board are no longer operating as they should?

Personally would have preferred that the XTAG3 interface pins be galvanic isolated along with some form of current protection.
MyDirtIsRed
Junior Member
Posts: 5
Joined: Wed Sep 12, 2018 7:36 pm

Postby MyDirtIsRed » Mon Sep 17, 2018 10:06 pm

mon2 wrote:On your testing with the XTAG3 tool, what are the details of your PC? Which OS?

Windows 10 ---> Vbox 5.1.26 ---> Ubuntu 12.04, 32-bit
mon2 wrote:Are you using the blue insulator USB ports (ie. USB 3.0 / aka USB 3.1 Gen1) or the black insulator USB ports (USB 2.0)? Where possible, stick to USB 2.0 ports.

All ports on this particular machine are superspeed ports.

Thank you very much for your help. I've got other aspects of this PCB to explore, but I will be having to program this thing as well, so other issues along these lines are bound to pop up.

Who is online

Users browsing this forum: No registered users and 225 guests