I am trying to load some code to a newly designed hardware platform.
The XTAG-2 cannot seem to find the L16 chip
The xTime Target error message is:
XMOS XTAG-2 connected to None [_I2U6OBg]
Trying to load code to new hardware
-
- XCore Addict
- Posts: 204
- Joined: Sun Jun 01, 2014 10:25 pm
-
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
There are two comms channels between your target and the host:
host <-> xtag <-> target chip.
The error message reported means that the host <-> xtag bit is OK, but there is no response from the target chip over JTAG. You would get the same message if XSYS (debug connection to your chip from the xtag) is disconnected.
So something fundamental is amiss here - either the chip is not correctly powered up (so JTAG TAP state machine not working) or JTAG is not connected properly (TDO/TDI/TMS/TCLK etc.).
So it's time to double check your schematics - Section G of the L16 HW manual https://www.xmos.com/download/public/XS ... 1.6%29.pdf has well tried and tested instructions for debug hookup, and section H has a comprehensive design checklist for life support signals for the chip, which needs to be met.
If you're sure schematics are OK, then continuity checking (difficult I know with this package depending on the design- some customers use xrays) is important (check for opens/shorts) and checking power supply draw/clock etc. This package does need the guidelines in section 10 to be followed.
FInally, this is worth checking http://www.xcore.com/questions/1902/wha ... ot-enabled
Good luck! Remember there are millions of boards made with this device, so it's going to be something solvable..
host <-> xtag <-> target chip.
The error message reported means that the host <-> xtag bit is OK, but there is no response from the target chip over JTAG. You would get the same message if XSYS (debug connection to your chip from the xtag) is disconnected.
So something fundamental is amiss here - either the chip is not correctly powered up (so JTAG TAP state machine not working) or JTAG is not connected properly (TDO/TDI/TMS/TCLK etc.).
So it's time to double check your schematics - Section G of the L16 HW manual https://www.xmos.com/download/public/XS ... 1.6%29.pdf has well tried and tested instructions for debug hookup, and section H has a comprehensive design checklist for life support signals for the chip, which needs to be met.
If you're sure schematics are OK, then continuity checking (difficult I know with this package depending on the design- some customers use xrays) is important (check for opens/shorts) and checking power supply draw/clock etc. This package does need the guidelines in section 10 to be followed.
FInally, this is worth checking http://www.xcore.com/questions/1902/wha ... ot-enabled
Good luck! Remember there are millions of boards made with this device, so it's going to be something solvable..
-
- XCore Addict
- Posts: 204
- Joined: Sun Jun 01, 2014 10:25 pm
OK thanks I will look at all that.
Two more questions:
What is the DEBUG line used for and is it necessary for the JTAG to work?
How does the compiler program the flash via XTAG2?
Two more questions:
What is the DEBUG line used for and is it necessary for the JTAG to work?
How does the compiler program the flash via XTAG2?
-
- XCore Expert
- Posts: 754
- Joined: Thu Dec 10, 2009 6:56 pm
The debug pin is used to synchronously put multiple xcores in debug mode. JTAG will work without but if you have the real estate to get it routed to your connector, I would do it. If I recall correctly it does need a pull-up resistor.
The flash is programmed by the tools by generating and building a special flash programming application that will be loaded by the XTAG2 and executed on your target processor and takes care of the programming of the flash.
The flash is programmed by the tools by generating and building a special flash programming application that will be loaded by the XTAG2 and executed on your target processor and takes care of the programming of the flash.
-
- XCore Addict
- Posts: 204
- Joined: Sun Jun 01, 2014 10:25 pm
I have checked out everything suggested. As you stated, there is no way to check continuity to the parts themselves.
I have two L16 devices on my design and I have daisy chained the TDO and TDI signals through both parts. Could this be the problem?
I have two L16 devices on my design and I have daisy chained the TDO and TDI signals through both parts. Could this be the problem?
-
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
Daisy chaining JTAG of two devices is perfectly OK - The tools will interrogate the chain and report which devices are in the chain. It's a technique we use for many internal multi-chip boards just fine.
You can see an example of chaining in the XK-1A schematic (where TDO is either forwarded to the next board if plugged in, or returned back to the X-SYS header)
https://www.xmos.com/download/public/XK ... 1.0%29.pdf
I wonder if there is a way to test continuity of the JTAG input pin connections, at least the exposed ones - perhaps you could place a high value resistor (a meg or so) pulled up to 5v on the pins to see if the ESD clamp diode does it's job. Outputs can obviously be probed/loaded with a resistor to see if they are being driven OK to the PCB.
The issue with a JTAG chain is that it only takes a single open to break it..
Perhaps also try to boot from SPI and see if CS gets asserted. Or maybe look at the supply rail currents on a scope using a shunt resistor to look for an AC component. This would at least tell you if it was being supplied OK and being clocked, which is a good start...
You can see an example of chaining in the XK-1A schematic (where TDO is either forwarded to the next board if plugged in, or returned back to the X-SYS header)
https://www.xmos.com/download/public/XK ... 1.0%29.pdf
I wonder if there is a way to test continuity of the JTAG input pin connections, at least the exposed ones - perhaps you could place a high value resistor (a meg or so) pulled up to 5v on the pins to see if the ESD clamp diode does it's job. Outputs can obviously be probed/loaded with a resistor to see if they are being driven OK to the PCB.
The issue with a JTAG chain is that it only takes a single open to break it..
Perhaps also try to boot from SPI and see if CS gets asserted. Or maybe look at the supply rail currents on a scope using a shunt resistor to look for an AC component. This would at least tell you if it was being supplied OK and being clocked, which is a good start...
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
Another thing to test is if your input clock is okay. I've
had JTAG not work before, when the clock was broken
(this was on an L2). Things miraculously worked with
that fixed.
had JTAG not work before, when the clock was broken
(this was on an L2). Things miraculously worked with
that fixed.
-
- XCore Addict
- Posts: 204
- Joined: Sun Jun 01, 2014 10:25 pm
Thanks for your suggestions, I will follow up on those today.
Segher, what do mean by input clock? The main CLK/PCU_CLK inputs or the JTAG TCK input.
I have checked the main clock, it is ok.
I have also checked with the assembly contractor and they have confirmed that the boards were x-rayed as part of the assembly process.
Segher, what do mean by input clock? The main CLK/PCU_CLK inputs or the JTAG TCK input.
I have checked the main clock, it is ok.
I have also checked with the assembly contractor and they have confirmed that the boards were x-rayed as part of the assembly process.
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
Hi Gerry,
I mean just CLK; the crystal or whatever you use.
Try to probe whatever signals you can; see if the voltages
are stable (and everything ramps up in the proper order);
check if the reset signals do something funky. Walk over
the checklists in the chip datasheet, see if you forgot
something; show us (the relevant part of) your schematics
(everything power, reset, clocks, JTAG, MODE).
And don't panic ;-)
I mean just CLK; the crystal or whatever you use.
Try to probe whatever signals you can; see if the voltages
are stable (and everything ramps up in the proper order);
check if the reset signals do something funky. Walk over
the checklists in the chip datasheet, see if you forgot
something; show us (the relevant part of) your schematics
(everything power, reset, clocks, JTAG, MODE).
And don't panic ;-)
-
- XCore Addict
- Posts: 204
- Joined: Sun Jun 01, 2014 10:25 pm
Discovered that the power sequencing does not meet the specification.
Working on a hardware/software work around solution.
Will post the results.......
Working on a hardware/software work around solution.
Will post the results.......