Custom Board 3xL2 not loading code

[Redeye]

I've created a custom board which uses 3xL2 processors which I sent to XMOS to design review before I got it made, and they pointed out a few errors which I fixed. Testing has gone pretty well right up to the point of trying to get XDE to load code via the XTAG2. It seems to recognise the board, it identifies the 6 cores (or whatever XMOS are calling them this week) [0..5], but when I try and debug a simple single core flashing LED test program I get :

connect --adapter-id YdI-kQJk
0x00010000 in main ()
load
Loading section .text, size 0x24c lma 0x10000
Loading section .globcode, size 0x3a lma 0x1024c
Loading section .cp.const4, size 0x4 lma 0x10288
Loading section .ctors, size 0x8 lma 0x1028c
Loading section .dtors, size 0x4 lma 0x10294
Loading section .dp.data, size 0x2c lma 0x10298
Start address 0x10000, load size 706
Transfer rate: 57 KB/sec, 117 bytes/write.

Warning: according to mode pins, system is not set to boot from JTAG
First stage multi-node boot failed, please check XN file and Xmos link connectivity


I've been through a dozen times and I cannot see where the problem is. It says the system isn't set to boot from JTAG, but when I look on the scope the !TRST line is getting pulled low so the mode pins should be correct for JTAG booting for all 3 processors. The relevant parts of the schematic are :

XTAG2+Config.png

Voltage Supervision.png

I've found and fixed one problem already - the SN74LVC2G17 on the !RST and !TRST lines have been changed to SN74LVC2G07 which are open drain outputs as they weren't getting pulled low by the XTAG2 with the schmitt triggers.

I've been through every pin of the XTAG2 on a scope and compared it to my XR-AVB-LC_BRD with the same code working correctly and can't see any obvious difference. I'm about out of ideas what to try next. I'm not sure I really understand why it thinks the boot mode pins are wrong, or how it's discovered that as I guess that's the first problem to solve. Any suggestions would be most welcome.

For completeness, this is the XN file I'm using :

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<Network xmlns="http://www.xmos.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.xmos.com http://www.xmos.com">
  <Type>Device</Type>
  <Name>3XL2</Name>
  <!-- Board Version 1V0 -->
  <!-- File Version 1V0 -->

  <Declarations>
    <Declaration>core stdcore[6]</Declaration>
  </Declarations>

  <Packages>
    <Package ID="0" Type="XS1-L2A-QF124">
	  <Nodes>
        <Node Id="0" Type="XS1-L1A" InPackageId="0" Oscillator="25MHz" SystemFrequency="500MHz">
		  <Boot>
			<Source Location="SPI:bootFlash"/>
			<Bootee NodeId="1"/>
			<Bootee NodeId="2"/>
			<Bootee NodeId="3"/>
			<Bootee NodeId="4"/>
			<Bootee NodeId="5"/>
		  </Boot>
		  <Core Number="0" Reference="stdcore[0]">
			<!-- SPI FLASH -->
			<Port Location="XS1_PORT_1A" Name="PORT_SPI_FLASH_MISO"/>
			<Port Location="XS1_PORT_1B" Name="PORT_SPI_FLASH_SS"/>
			<Port Location="XS1_PORT_1C" Name="PORT_SPI_FLASH_CLK"/>
			<Port Location="XS1_PORT_1D" Name="PORT_SPI_FLASH_MOSI"/>
			
			<!-- System Active LED -->
			<Port Location="XS1_PORT_1G" Name="PORT_SYS_ALIVE_LED"/>
			
		  </Core>
		</Node>
        <Node Id="1" Type="XS1-L1A" InPackageId="1" Oscillator="25MHz" SystemFrequency="500MHz">
		  <Boot>
			<Source Location="XMOSLINK"/>
		  </Boot>
		  <Core Number="0" Reference="stdcore[1]">
		  </Core>
		</Node>
	  </Nodes>
    </Package>
    <Package ID="1" Type="XS1-L2A-QF124">
      <Nodes>
       <Node Id="2" Type="XS1-L1A" InPackageId="0" Oscillator="25MHz" SystemFrequency="500MHz">
          <Core Number="0" Reference="stdcore[2]">	
          </Core>
          <Boot>
             <Source Location="XMOSLINK"></Source>
          </Boot>
       </Node>
       <Node Id="3" Type="XS1-L1A" InPackageId="1" Oscillator="25MHz" SystemFrequency="500MHz">
          <Core Number="0" Reference="stdcore[3]">
          </Core>
          <Boot>
             <Source Location="XMOSLINK"></Source>
          </Boot>
        </Node>
     </Nodes>
    </Package>
    <Package ID="2" Type="XS1-L2A-QF124">
      <Nodes>
       <Node Id="4" Type="XS1-L1A" InPackageId="0" Oscillator="25MHz" SystemFrequency="500MHz">
          <Core Number="0" Reference="stdcore[4]">		 
          </Core>
          <Boot>
             <Source Location="XMOSLINK"></Source>
          </Boot>
       </Node>
       <Node Id="5" Type="XS1-L1A" InPackageId="1" Oscillator="25MHz" SystemFrequency="500MHz">
          <Core Number="0" Reference="stdcore[5]">
          </Core>
          <Boot>
             <Source Location="XMOSLINK"></Source>
          </Boot>
        </Node>
     </Nodes>
    </Package>
  </Packages>

  <Links>
    <!-- XScope -->
    <Link Encoding="2wire" Delays="4,4" Flags="SOD">
      <LinkEndpoint NodeId="0" Link="X0LA"/>
      <LinkEndpoint RoutingId="0x8000" Chanend="1"/>
    </Link>
    <!-- L2 Internal L2-0 -->
    <Link Encoding="5wire" Delays="0,1">
      <LinkEndpoint NodeId="0" Link="4"/>
      <LinkEndpoint NodeId="1" Link="7"/>
    </Link>
    <Link Encoding="5wire" Delays="0,1">
      <LinkEndpoint NodeId="0" Link="5"/>
      <LinkEndpoint NodeId="1" Link="6"/>
    </Link>
    <Link Encoding="5wire" Delays="0,1">
      <LinkEndpoint NodeId="0" Link="6"/>
      <LinkEndpoint NodeId="1" Link="5"/>
    </Link>
    <Link Encoding="5wire" Delays="0,1">
      <LinkEndpoint NodeId="0" Link="7"/>
      <LinkEndpoint NodeId="1" Link="4"/>
    </Link>
    <!-- L2 Internal L2-1 -->
    <Link Encoding="5wire" Delays="0,1">
      <LinkEndpoint NodeId="2" Link="4"/>
      <LinkEndpoint NodeId="3" Link="7"/>
    </Link>
    <Link Encoding="5wire" Delays="0,1">
      <LinkEndpoint NodeId="2" Link="5"/>
      <LinkEndpoint NodeId="3" Link="6"/>
    </Link>
    <Link Encoding="5wire" Delays="0,1">
      <LinkEndpoint NodeId="2" Link="6"/>
      <LinkEndpoint NodeId="3" Link="5"/>
    </Link>
    <Link Encoding="5wire" Delays="0,1">
      <LinkEndpoint NodeId="2" Link="7"/>
      <LinkEndpoint NodeId="3" Link="4"/>
    </Link>
    <!-- L2 Internal L2-2 -->
    <Link Encoding="5wire" Delays="0,1">
      <LinkEndpoint NodeId="4" Link="4"/>
      <LinkEndpoint NodeId="5" Link="7"/>
    </Link>
    <Link Encoding="5wire" Delays="0,1">
      <LinkEndpoint NodeId="4" Link="5"/>
      <LinkEndpoint NodeId="5" Link="6"/>
    </Link>
    <Link Encoding="5wire" Delays="0,1">
      <LinkEndpoint NodeId="4" Link="6"/>
      <LinkEndpoint NodeId="5" Link="5"/>
    </Link>
    <Link Encoding="5wire" Delays="0,1">
      <LinkEndpoint NodeId="4" Link="7"/>
      <LinkEndpoint NodeId="5" Link="4"/>
    </Link>
    <!-- L2 External L2-0 to L2-1 -->
    <Link Encoding="5wire" Delays="4,4">
      <LinkEndpoint NodeId="1" Link="X0LA"/>
      <LinkEndpoint NodeId="2" Link="X0LA"/>
    </Link>
    <Link Encoding="5wire" Delays="4,4">
      <LinkEndpoint NodeId="1" Link="X0LB"/>
      <LinkEndpoint NodeId="2" Link="X0LB"/>
    </Link>
    <!-- L2 External L2-1 to L2-2 -->
    <Link Encoding="5wire" Delays="4,4">
      <LinkEndpoint NodeId="3" Link="X0LA"/>
      <LinkEndpoint NodeId="4" Link="X0LA"/>
    </Link>
    <Link Encoding="5wire" Delays="4,4">
      <LinkEndpoint NodeId="3" Link="X0LB"/>
      <LinkEndpoint NodeId="4" Link="X0LB"/>
    </Link>
  </Links>

  <ExternalDevices>
    <Device NodeId="0" Core="0" Class="SPIFlash" Name="bootFlash" Type="Atmel_AT25DF321A">
      <Attribute Name="PORT_SPI_MISO" Value="PORT_SPI_FLASH_MISO"/>
      <Attribute Name="PORT_SPI_SS"   Value="PORT_SPI_FLASH_SS"/>
      <Attribute Name="PORT_SPI_CLK"  Value="PORT_SPI_FLASH_CLK"/>
      <Attribute Name="PORT_SPI_MOSI" Value="PORT_SPI_FLASH_MOSI"/>
    </Device>
  </ExternalDevices>

  <JTAGChain>
     <JTAGDevice NodeId="0"/>
     <JTAGDevice NodeId="1"/>
     <JTAGDevice NodeId="2"/>
     <JTAGDevice NodeId="3"/>
     <JTAGDevice NodeId="4"/>
     <JTAGDevice NodeId="5"/>
  </JTAGChain>
 
</Network>

[lilltroll]

Is the XCORE RST_N connected to XTAG pin 15 (via open drain buffer etc) ?
The XTAG2 should be able to drive both RST_N and TRST_N low I think, as in this one (that has a very simple PowerOn Reset), https://www.xmos.com/download/private/X ... 28A%29.pdf

[Redeye]

Hi liltroll,

I was just about to post a reply politely pointing out that I wouldn't do anything that stupid, but on closer inspection it looks like you're absolutely right and I am that stupid!

I've scoped the RST_N and TRST_N at the XTAG2 and they're both correct and pulling low as they should. However, despite the fact that I've been over this part of the circuit dozens of times, I've missed the fact that the signal labelled RST_JTAG which is driven to/from the XTAG2 can't pull RST_1, RST_2 or RST_3 low. It looks like I need to change the input for the RST_1, RST_2 and RST_3 buffers to come from the RST_JTAG signal, instead of directly from U25.

That does also explain why the JTAG thinks the mode pins are wrong because it means the processors aren't being reset so the processor will still think it's set to boot from SPI flash.

I'll have a go at doing the mod to the circuit later today and let you know if it works.

As a minor aside, this PCB would have been a lot easier to design if XMOS had a multi processor reference design. For all the talk of XLinks and how easy it is to make multi processor systems, as far as I know there aren't actually any examples showing how it's done.

[lilltroll]

Actually, I made the same error myself, drawing a quad L1 schematics with isolated L-Links this weekend.
You think you have understood the secrets with the reset pin after making the "3.3V -> 1.0V -> delay -> reset " in the schematics.
I spotted it since it was too strange to have pin 15 on the XTAG not connected to the XCORE, and in the XK1-a schematics it was an obvious connection in the schematics.

It should be included in the L1-checklist if not already there - I am not there yet with my schematics.

[Redeye]

liltroll - Thanks so much, you spotted the main problem and after finding and fixing that and a couple of others (somehow a couple of component labels had got switched and there was an error in the XN file) I've now got a 6 core main() working!!! It's all just dummy threads running counters and flashing LEDs at the moment, but I'm hoping the fact that it's loaded the code and it runs means that the PCB is basically working and my XLinks are connected correctly. I'll test more tomorrow, but for now I'm just going to enjoy the feeling of relief!!!

Thanks again, I really appreciate you taking the time to look at this. If I can return the favour by checking your schematic, please just ask and I'll do my best.

[pstnotpd]

I've now got a 6 core main() working!!!

Shouldn't that be "6 tiles" in newspeak? ;o)

Anyway, sounds great. Any chance of a "slice" version? As stated elsewhere I'm wondering if something like that would be possible.

[Folknology]

From memory, isn't the xsys debug pin tristate and bidirectional?

regards
Al

[Redeye]

Folknology - If I'm honest I'm not sure I really understand what the debug pin is for. I think the (slightly sparse) documentation says something about it being used for multi-core debugging but in the absence of any other explanation that I've found, or a multi processor example schematic (hint, hint XMOS) that's about all I know.

I did send the schematic to XMOS for design review before I got the board made, and it was them that pointed me to the errata in the datasheet that recommends buffering for several of the JTAG pins in multi processor designs.

Anyway, the board seems to run and debug fine as it is so far - I've got code running on all 6 cores, the Xlinks are all working fine, it boots from flash, the ethernet port works, I can hit breakpoints in the code. The only strangeness I've got so far is that I've not managed to get XScope working, although I've found it to be pretty flaky even on XMOS designed boards so I've not delved too deep into that problem yet.

[segher]

Folknology - If I'm honest I'm not sure I really understand what the debug pin is for.

The debug pin on the chips is for generating "debug interrupts", just like
the JTAG programmers generate. Such an interrupt halts all threads except
thread #0, which starts executing the debug handler.

You can configure the debug pin (per core) to be activated when a debug
interrupt fires, or to fire a debug interrupt when the pin is activated. This
way, all the cores in a system will halt together.

I think the (slightly sparse) documentation says something about it being used for multi-core debugging

"Slightly" sparse, you're very polite aren't you :-)

Anyway, I've never found the DEBUG signal useful myself, but then again
I never use breakpoints either. If you're into step-and-pray style of debugging,
it probably is useful for you.

I don't know why it is connected to the XSYS, nothing uses it AFAIK?

[Redeye]

Thanks segher, that explains things more than the documentation does (as you can tell I'm not really that impressed with the documentation - not sure why XMOS felt the need to spend a small fortune on a new logo and changing all the naming conventions for cores etc when the time and money could have been better spent on improving the content).

So, if all the debug pin is effectively both an in and out port then on a multi processor system they should all be connected directly together then? I can't think of a way you could buffer them (as the errata suggests) in that case. Am I missing something, or have I misunderstood?