Trying to load code to new hardware

[gerrykurz]

OK after a few frustrating days struggling with arm tool chains, I finally have the power sequencing correct and the parts coming out of reset and trying to boot from flash.

However, the jtag still does not recognize the parts. I will look into that some more but in the worst case scenario, the arm micro can program the flash and the xmos chips can then boot from flash.

[gerrykurz]

I have hooked up a logic analyzer to the jtag interface to both the XP_SKC_L2 slice kit board and to my board. The TMS and TCK are working on both, and the initial TDO output is working on both but the TDO signal is different on the L2 and my board.

Is there some detailed information on what the chain of events/commands are when the JTAG starts up?

I need some help here, I can monitor the signals but I need to know what to expect to see.

I have attached the test results.

[segher]

Hi again,

Does your TRST function correctly?

[gerrykurz]

What do you mean by correctly? What is the expected behavior?

When I did the initial data capture on the slice kit boards, TRST was not active and did not appear to be used to initialize communications with the chips.

[segher]

The datasheets describe this, IIRC.

Importantly, at system reset time TRST should be pulled.
It is also active when the XTAG is "connected" I think.

[gerrykurz]

OK, I have fixed the TRST at power-up issue.

Now the power supplies are sequenced properly and both TRST and RST are held low through power up and released after 100 ns as per the datasheet.

xTime Composer 13.2.0 still cannot find the L16 devices on the JTAG interface.

I have loaded and looked at the proj_xtag2 code and it seems the actual JTAG protocol is in some library files that are not part of the project. Right under the binaries folder there is something called includes and in it are what look to be references to other source files and header files. Where do I find the files sc_jtag/module_jtag_master/src and sc_jtag/module_xcore_debug/src?

If I have to debug this, I need some documentation about what is going on at the jtag protocol level.

I am at a loss as to what more to try.

[infiniteimprobability]

Thanks for the update.

Sounds like you have made progress but I sense the frustration that it still hasn't come up in JTAG, which is pretty much essential to get developing..

I am at a loss as to what more to try.

The most important thing is to establish that data is coming back out of TDO from the last chip in the chain. Can you confirm that?

Based on seeing a few support requests like this, I'd still suspect continuity on the JTAG chain connections. Millions of L16 chips are in end products, but we know from experience that the 124 pin LGA package is sensitive to the soldering process (which is why there are comprehensive guidelines for the stencils etc. in the datasheet). The most common one I have seen is not following the ground pad stencil layout of four squares of solder paste (figure 15), which results in the chip "floating" upwards and causing opens on the signal pins. No issues though when the guidelines are followed.

Since the chips seem to boot from SPI OK, I'd strongly recommend to focus on the JTAG connections rather than reverse engineering the proj_xtag2 code, especially as this project is not kept up to date. The code in the latest tools for talking to multiple devices via a JTAG chain is very stable - some of devices work this way internally and there are countless multi-chip boards out there using the same tool, so we have a high degree of confidence in this approach.

Were you able to confirm continuity on the JTAG pins using the weak pull up to a highish voltage technique? I appreciate this may be tricky on lines which are paralleled like TCLK/TRST.

[gerrykurz]

Yes, I have confirmed that data is coming out of TDO in the last chip in the chain however the data is different than the data coming out of the reference design using two slice kits chained together.

Attached is a photo of the data coming from TDO on my hardware. (please see all the photos from a previous post)

One thing I have noticed is that the SCLK to the flash when the chip comes out of reset and tries to boot is half the speed it is supposed to be according to the data sheet.

To confirm the continuity to input pins as you suggest will involve cutting a lot of traces on the board, likely rendering it unusable. I would be more inclined to have the board xrayed to the solder joints although the assembler claims to have done this.

[segher]

The image shows it scanning out a single bit 0 (from a
bypass reg, OTP I think, not important what exactly)
followed by hex 2633, the IDCODE for L devices. This
is exactly as expected after reset. What do you see
differently on a working system?

Seeing the SPI boot using a too slow clock suggests your
MODE0,1 are wrong. What speed do you see, with what
crystal (or oscillator, etc.) freq?

[segher]

Oh, another thing. The image shows only the begin of
the TDO output; what happens next is more interesting.

It is scanning in all ones; what should come out is a zero
for every bypass reg, the IDCODE for everything that
identifies itself (32 bits, low bit a one), and then what
you scanned in (all ones).

My suspicion is you see all zeroes instead, and your TDI
is broken.