I am trying to get a simple program working across 2 XC-1As connected with a single xlink. I know there are lots of problems involved with timing etc but hey, who doesn't like a challenge!
Hopefully a simple question to start, page 4 of the XS1-G Link Guidelines lists the names of the various links that can be put in the .xn file. Page 9 of the XC-1A Hardware Manual gives the corresponding pins to the ports. They don't seem to obviously match up to me so am I right in thinking that a 5 bit xlink using X3PortA should be X3LA in the Links part of the .xn file?
Thought I'd start with the obvious and make sure I'm plugging the cable into the right place!
Here is my .xn file in case it helps
Xlink between 2 XC-1As
-
- Member++
- Posts: 28
- Joined: Tue Mar 15, 2011 3:29 pm
-
- Experienced Member
- Posts: 69
- Joined: Mon May 17, 2010 10:19 am
Yes, X3LA is the right one.
-
- Member++
- Posts: 28
- Joined: Tue Mar 15, 2011 3:29 pm
Ok. Essentially I found this forum post from a couple of years ago about linking two XC-1s up and I'm trying to adapt it to the XC-1A and new tools.
This is the zip file with their implementation.
The method involves splitting the executable into a first-stage loader for each board and then the application for each board using xobjdump.
This is my bat file to do the splitting.
I can't work out what the difference is between what it puts into boardA.xe and appA.xe
The command for boardA specifies the node whereas the one for appA.xe doesn't but I'm not sure how the resulting .xe files differ?
This is the zip file with their implementation.
The method involves splitting the executable into a first-stage loader for each board and then the application for each board using xobjdump.
This is my bat file to do the splitting.
I can't work out what the difference is between what it puts into boardA.xe and appA.xe
Code: Select all
xobjdump boardA.xe -a "%XCC_DEVICE_PATH%/config_XS1-G4B-FB512.xml"
xobjdump boardA.xe -a "%XCC_DEVICE_PATH%/XS1-G4B-FB512.xn"
xobjdump boardA.xe -a 0,0,image_n0c0.elf
xobjdump boardA.xe -a 0,1,image_n0c1.elf
xobjdump boardA.xe -a 0,2,image_n0c2.elf
xobjdump boardA.xe -a 0,3,image_n0c3.elf
Code: Select all
xobjdump appA.xe -a "%XCC_DEVICE_PATH%/config_XS1-G4B-FB512.xml"
xobjdump appA.xe -a "%XCC_DEVICE_PATH%/XS1-G4B-FB512.xn"
xobjdump appA.xe -a 0,image_n0c0_2.elf
xobjdump appA.xe -a 1,image_n0c1_2.elf
xobjdump appA.xe -a 2,image_n0c2_2.elf
xobjdump appA.xe -a 3,image_n0c3_2.elf
-
- Experienced Member
- Posts: 69
- Joined: Mon May 17, 2010 10:19 am
The elves put into boardA.xe have an "_2" in their filenames. When xobjdump splits the original XE it produces two binaries for each node/core. The first (the loader) is image_nXcY.elf the second (the application) is image_nXcY_2.elf.tomcarter259 wrote:I can't work out what the difference is between what it puts into boardA.xe and appA.xe
-
- Member++
- Posts: 28
- Joined: Tue Mar 15, 2011 3:29 pm
Great thanks for clearing that up.
I have set core[0] to flash the button LEDs to indicate that the application has loaded and is running properly. However nothing happens when I run the application image.
I can't imagine that this could be caused by the xlink failing to connect so is it likely to be a problem with the way I am doing the splitting?
I have set core[0] to flash the button LEDs to indicate that the application has loaded and is running properly. However nothing happens when I run the application image.
I can't imagine that this could be caused by the xlink failing to connect so is it likely to be a problem with the way I am doing the splitting?
-
- Experienced Member
- Posts: 69
- Joined: Mon May 17, 2010 10:19 am
Experience suggests that it is most probably caused by the xlinks failing to connect. The G4 links are tetchy and problems are difficult to diagnose without a scope.tomcarter259 wrote:I can't imagine that this could be caused by the xlink failing to connect so is it likely to be a problem with the way I am doing the splitting?
Also do you have firmware installed on the boards? There's an undocumented feature in some XC-1 firmwares which divides down the switch's clock so that it can no longer talk to normal speed switches. A program which reports the value of SSWITCH_CLK_DIVIDER whether this is the case on any of your boards.
-
- Member++
- Posts: 28
- Joined: Tue Mar 15, 2011 3:29 pm
The boards have the firmware they came with still on them. How would I output the value of SSWITCH_CLK_DIVIDER? The compiler doesn't recognise it and I can't find any reference to it in the documentation.m_y wrote:Also do you have firmware installed on the boards? There's an undocumented feature in some XC-1 firmwares which divides down the switch's clock so that it can no longer talk to normal speed switches. A program which reports the value of SSWITCH_CLK_DIVIDER whether this is the case on any of your boards.
-
- Experienced Member
- Posts: 69
- Joined: Mon May 17, 2010 10:19 am
Code below. A value of 0x00 runs the switch at the maximal clock rate, 0xff at the lowest. Some XC-1 firmwares seem to program it to 0x80.
Code: Select all
#include <platform.h>
#include <xs1.h>
#include <stdio.h>
int main()
{
par
{
on stdcore[0]:
{
unsigned int val;
read_sswitch_reg( 0, XS1_SSWITCH_CLK_DIVIDER_NUM, val );
printf("Reg 7: 0x%08x\n",val);
}
}
return(0);
}
-
- Member++
- Posts: 28
- Joined: Tue Mar 15, 2011 3:29 pm
My boards all had 0x00m_y wrote:A value of 0x00 runs the switch at the maximal clock rate, 0xff at the lowest. Some XC-1 firmwares seem to program it to 0x80.
So would the only way to work out why its failing be to scope what's happening over the link?
-
- Experienced Member
- Posts: 69
- Joined: Mon May 17, 2010 10:19 am
The method described in the links above works for suitably configured boards; I reconfirmed it myself a couple of weeks ago with pairs of XC-1s and XC-2s. Unfortunately the G4 links are almost completely opaque to software so it's very difficult to divine what's happening without spending a great deal of time picking over the entrails of the failing system. A scope is very useful at this stage, yes.tomcarter259 wrote:So would the only way to work out why its failing be to scope what's happening over the link?