Debugging SPI Boot

[infiniteimprobability]

Glad it's booting now. Some excellent debugging input from Segher helps ;-)

I meant to ask - is there any reason why you are sticking with such an old major release of the tools?

We've fixed a lot of multi-tile issues in the past few releases..especially tools 13.

http://www.xmos.com/en/download/public/ ... %3A-13.txt

[segher]

I meant to ask - is there any reason why you are sticking with such an old major release of the tools?

[I'm not speaking for bearcat of course, but since he didn't reply yet...]

I imagine it has something to do with the fact that new tools are not compatible with old source code and object files, and the other way around? Very annoying, especially since there is no technical reason for it at all.

[bearcat]

As segher said.

My code is customized from an older version of the reference design. So I will not been able to move forward. I would be happier with a compatibility switch on the newer versions of XDE.

So far, so good, though. Debugging on 11.11.1, and building the image on 11.2.2 is booting and I have not found any side effects yet. Still have to build 2 more expansion cards to test the full 10 tile design.

Thanks for everyone's help.

[bearcat]

Well, all is not so good using 11.2.2. When I finally tried an upgrade image, things didn't work.

So I'm back to square one. I went ahead and started using XDE 12.2.0 to see if something has been fixed. I ported my Slim/DFU code over to it with all the latest modules (porting my application is not attempted yet). It runs just fine from XDE with the USB device enumerated and shown as a DFU device. So far so good.

When I flash it, it doesn't work either. In fact, it blocks at the exact same address as with 11.11.1.

I am no expert yet on loadable modules and elf's (which I prefer not to be). But it appears to have gotten to load loadable 2, which is the application, as I see it in memory. So it has gotten quite aways into the boot process. But one thing I don't understand, is the code is offset by 32 bytes in memory. Instead of address 0x10000, the code starts at 0x10020?? If there are any absolute jumps, this will definately blow up. When debugging thru XDE, it does start at 0x10000.

I've gone through things with a fine tooth comb, and have not found what is probably some stupid error here. I am going to test with my last design and code, as it works best I know and see where and how it is booting.

The code up at 0x1f1e8 is completely unknown to me (where it blocks). It's in ram, but nowhere found in the object dump. I thinking this must be the code that loads the loadable.

Any ideas on what could be the problem? Code offset by 32bytes?

[bearcat]

Looking at the code in more detail, I see tile1 is trying to receive the code from tile0 and is from the bootrom. Presumably the code on tile0 is trying to send it, looks like it.

Attached is a picture of the Xlinks at boot up. Blue is tile0, yellow tile1. There is activity that looks reasonable. Without more knowledge, I can't really guess as to correctness. But there is no matching yellow pulse at the end?

But, it appears that it is sending out the right XLINK, so I assume the routing is correct. I verified the links are low at reset. The XLINKS work fine in the application, so I can't see how there's a problem with them. If the bootrom uses 1.25MHz for the link speed, that's not a problem either.

Tile1 is waiting for the first word, which appears to be a resource to use to load the rest of the code sent by tile0.

I am assuming the first set of data is the hello sequences.

V5 Boot Xlink.JPG

[bearcat]

Ok, so now I think I understand a little more. The code at 0x10000 or so, is probably the code to send over the XLINK, so maybe that's why it's not aligned. Although, the code there doesn't match any of the loadable elf's (or maybe I got the wrong object dump I was looking at).

The data it is trying to send, also is up high in memory and only 14 words long? Who knows..

Seeing that 11.2.2 is bootable on board, I have to believe it's something in the compiled boot code on tile0. I had used the same code between 11.2.2 and 11.11.1, with only the -g option removed and all the volatile's removed around my inline asm's. For 12.2.2, there were more changes. They all work thru the JTAG.

I am now using the 48 pin part as the boot tile. Any issues there?

[richard]

I am no expert yet on loadable modules and elf's (which I prefer not to be). But it appears to have gotten to load loadable 2, which is the application, as I see it in memory. So it has gotten quite aways into the boot process. But one thing I don't understand, is the code is offset by 32 bytes in memory. Instead of address 0x10000, the code starts at 0x10020??

I don't think it has made it into your application, I think it is still in the flash loader. The flash loader is responsible for setting up the network and loading images onto each tile. There is a header at a fixed address from the start of flash that lies inside the flash loader, so the flash loader starts with a jump over this data structure. This is what you are seeing in the disassembly.

I suspect it has hung somewhere in the network setup part of the flash boot. How many devices are there in your network and how are they connected? Do they all boot from a single flash or do you have multiple flash boot sites?

[bearcat]

The system is expandable. It can have from 2 to 10 tiles, which I handle with compiler conditionals and different XN files. At the minimum, it contains 2, which is what the slim/DFU version of my code is coded for, and doesn't boot. Attached is the latest XN file for it on 12.2.0. 48 pin L1 is the spi boot, with a single 64 pin L1 attached to XLINKC (XLINKB on the 64). Using XLINKC on the 48 pin part is the only new architecture on this board, over the last board at this minimum configuration. At 10 tiles, they are simply a linear array of 48 pin L1's except for the one 64 pin at Tile1. All tiles are booted from Tile0 SPI. XLINKB tied to a prior XLINKC (except for the 1 64 pin which uses XLINKA). Through all the iterations, I have never seen a compiled 11.11.1 or 12.2.0 code ever boot. But version 11.2.2 has been working always, until I tried an upgrade image. An upgrade image does boot with 11.2.2 with my last board that had used 2 64 pin L1's, with XLINKA boot tied to XLINKB.

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>Board</Type>
  		<Name>XDSP</Name>

	<Declarations>
    	<Declaration>tileref tile[2]</Declaration>
	</Declarations>
  
	<Packages>
    	<Package id="USB" Type="XS1-LnA-64-TQ48">
			<Nodes>
				<Node id="USB" Type="XS1-L8A-64" InPackageId="0" oscillator="13Mhz" systemfrequency="500MHz" referencefrequency="100MHz">
					<Boot>
						<Source Location="SPI:bootFlash"/>
						<Bootee NodeId="AUDIO" Tile="0"/>
					</Boot>
					<Tile Number="0" Reference="tile[0]">
						<Port Location="XS1_PORT_1A" Name="PORT_SPI_MISO"/>
						<Port Location="XS1_PORT_1B" Name="PORT_SPI_SS"/>
						<Port Location="XS1_PORT_1C" Name="PORT_SPI_CLK"/> 
						<Port Location="XS1_PORT_1D" Name="PORT_SPI_MOSI"/>
					</Tile>
				</Node>
			</Nodes>
		</Package>
    	<Package id="AUDIO" Type="XS1-LnA-64-LQ64">
			<Nodes>
				<Node id="AUDIO" Type="XS1-L8A-64" InPackageId="0" oscillator="12288KHz" systemfrequency="500MHz" referencefrequency="100MHz">
      				<Boot>
        				<Source Location="LINK"/>
      				</Boot>
      				<Tile Number="0" Reference="tile[1]">
					</Tile>
				</Node>
			</Nodes>
    	</Package>
	</Packages>
  
	<Links>
		<Link Encoding="2wire" Delays="6,6">
			<LinkEndpoint NodeId="USB" Link="X0LC"/>
			<LinkEndpoint NodeId="AUDIO" Link="X0LB"/>
		</Link>
	</Links>

	<ExternalDevices>
		<Device Nodeid="USB" Tile="0" Name="bootFlash" Class="SPIFlash" Type="AT25DF041A">
			<Attribute Name="PORT_SPI_MISO" Value="PORT_SPI_MISO"/>
			<Attribute Name="PORT_SPI_SS"   Value="PORT_SPI_SS"/>
			<Attribute Name="PORT_SPI_CLK"  Value="PORT_SPI_CLK"/>
			<Attribute Name="PORT_SPI_MOSI" Value="PORT_SPI_MOSI"/>
		</Device>
	</ExternalDevices>

	<JTAGChain>
		<JTAGDevice Nodeid="USB" Position="0"/>
		<JTAGDevice Nodeid="AUDIO" Position="1"/>
	</JTAGChain>

</Network>

[richard]

How are the mode pins set for each device? We have seen issues in the past in cases where the intial clock frequency (as determined by the mode pins) differs significantly from the final clock frequency (as determined by SystemFrequency attribute in the .xn).

[bearcat]

Clock doesn't change. Tile0 = 13MHz. Tile1 = 12.288MHz.

Tile0

L1-48.JPG

Tile1

L1-64.JPG

Run or debug jumper doesn't make any difference. I don't change any clocking in the code.