Hello,
I am very confused about an issue of the XtimeComposer 14. I have a very simple program that chains two slicekits togheter running perfectly on XtimeComposer 13.2.2. I created a new project with 14.0.4 and configured it the same way running the same code. The problem occures, when I want to start the program without debugger from flash. The chained slicekit just keeps waiting and the slicekit one(Master) does not correctly load the program as it does with 13.2.2. Slicekit two(slave) just keeps waiting in reset.
xrun --dump-state information is confusing me as well:
Thread 1 (tile[0] core[0]): pc 0x10744 67396 (program hangs at some point in the user program)
all other pc's are at position 0xffffc0a6 (Boot mode channels ,waiting for boot image) (correct?)
somehow in 14.0.4 the program is not loaded to all cores.
The used .xn file you can find under:
http://www.xcore.com/sites/default/file ... rm.xn_.txt
and I attached a zip with the two projects for the Xtime composer 13.2.2 and 14.0.4.
I would be very happy if someone(best would be from xmos) could have a look at this problem, run the projects as I attached it and tell me if he has the same issues!
Thank you in advance!
XtimeComposer 14 bad behaviour with Slicekit Chains
-
hegt
- Member++
- Posts: 19
- Joined: Wed Sep 17, 2014 1:20 pm
XtimeComposer 14 bad behaviour with Slicekit Chains
You do not have the required permissions to view the files attached to this post.
-
myndideal
- Active Member
- Posts: 59
- Joined: Thu May 05, 2011 10:00 pm
- Location: Budapest
Hi hegt,
which version of the slicekit you have? I have 1v1 and 1v2 version of the cpu board (Iam using same way, connected together).
I just write a lot here with a tech bullshit generator, so probably a huge part of this text is not relating to your actual situation... If you have time, take a look here:
When I use the earlier version board, I can easily run to some kind of failure state depending on what is in the flash, or was it used before, or what I did after the cold reset, is it the soldering station switching (just kidding). There is one documented issue which have a workaround and 1v2 version already fixed. It is related to rst_n signal basically, which can takes effect if we try to re-load or re-flash something to the already booted system. app_coreboard_1v1_flash_reset. (good to know)
Furthermore, as I mentioned before, two simply momentums are here:
-xtag2 stops booting the device at all, if it is connected. This can be a good question if it is a bug or a feature... (I dont know exactly how can be disabled this behaviour officially, but the easyest and fastest way is to disconnect the xtag2 while you are booting from spi flash.)
-the boot order is important. This is not a hot-plugable system, the slave device PC must be running in the right point in boot code, when the master try to connect by xlink to send the pgm image. Therefore the power connectors have to be connected in a strict order. Boot timings not so important, there is some retry counter, so... I can reproduce your failure state easily, if i did not reset the slave board.
I just found this pdf today:) Yet another documentation which contains some details about booting process is here: XS1-L-System-Specification ( there are more deailed description about the boot order, what I just guessed yesterday)
Next point which can be curious is a lil'bit deeper. xflash works that way: It generates a compressed image (for each tile) based on your only one xe binary. So literally we have more than one images. These are stored somewhere in your user temp directory, while the xflash doing its job. Furthermore -usually- some downloader code (which one is not written by you) is generated based on your xn file. This small code snipets will be used in your device to do some SPI flash programming tasks. This code snipets are used only at the moment when you are flashing the device (I think). And it is looks somehow different depending on your xn file, so it is generated by xTIMEcomposer pack actual version differently. (Probably there's differences in version 13 and 14 which drives 14.0.4 to failure) I still have only 14.0.3 version installed here, so I dont know...
And may be, it can be happened when something broke this spi writer xflash process (communication issue/noise whatever) to keeps the system in a half programmed state, and after booting the user code (which one generated by xflash) runs (obviously to failure state)... So that information if you seen a RAM address in core0 PC, not necessarily means this is your code :). (normally yes, it is... But it can be a part of the decompressor rutine too in case of previous failure).
Furthermore, the genuine boot loader have some conception to achive a nice updateable system. Therefore it is important what is it stored in the flash, because the bootloader handles multiple partitions, and try to load the latest partition... (Probably this is not an issue here, but good to know).
Yesterday I did tried to run / flash to your code to my boards, and it was running. I mean it could be run here, but I was able to fckup the process if I does something as I intended to test the unhandled failure cases...
I suggest to start with a clean flash content using xflash utility. To do this, probably you need the above v1.1 workaround if you own that board. (if the xflash does not finish success) And some --verbose option could be helpful on each step, to recognise what happened.
I agree, it would be nice to have a step-by-step documentation for the typical situations, or some collection of the all known cases...
which version of the slicekit you have? I have 1v1 and 1v2 version of the cpu board (Iam using same way, connected together).
I just write a lot here with a tech bullshit generator, so probably a huge part of this text is not relating to your actual situation... If you have time, take a look here:
When I use the earlier version board, I can easily run to some kind of failure state depending on what is in the flash, or was it used before, or what I did after the cold reset, is it the soldering station switching (just kidding). There is one documented issue which have a workaround and 1v2 version already fixed. It is related to rst_n signal basically, which can takes effect if we try to re-load or re-flash something to the already booted system. app_coreboard_1v1_flash_reset. (good to know)
Furthermore, as I mentioned before, two simply momentums are here:
-xtag2 stops booting the device at all, if it is connected. This can be a good question if it is a bug or a feature... (I dont know exactly how can be disabled this behaviour officially, but the easyest and fastest way is to disconnect the xtag2 while you are booting from spi flash.)
-the boot order is important. This is not a hot-plugable system, the slave device PC must be running in the right point in boot code, when the master try to connect by xlink to send the pgm image. Therefore the power connectors have to be connected in a strict order. Boot timings not so important, there is some retry counter, so... I can reproduce your failure state easily, if i did not reset the slave board.
I just found this pdf today:) Yet another documentation which contains some details about booting process is here: XS1-L-System-Specification ( there are more deailed description about the boot order, what I just guessed yesterday)
Next point which can be curious is a lil'bit deeper. xflash works that way: It generates a compressed image (for each tile) based on your only one xe binary. So literally we have more than one images. These are stored somewhere in your user temp directory, while the xflash doing its job. Furthermore -usually- some downloader code (which one is not written by you) is generated based on your xn file. This small code snipets will be used in your device to do some SPI flash programming tasks. This code snipets are used only at the moment when you are flashing the device (I think). And it is looks somehow different depending on your xn file, so it is generated by xTIMEcomposer pack actual version differently. (Probably there's differences in version 13 and 14 which drives 14.0.4 to failure) I still have only 14.0.3 version installed here, so I dont know...
And may be, it can be happened when something broke this spi writer xflash process (communication issue/noise whatever) to keeps the system in a half programmed state, and after booting the user code (which one generated by xflash) runs (obviously to failure state)... So that information if you seen a RAM address in core0 PC, not necessarily means this is your code :). (normally yes, it is... But it can be a part of the decompressor rutine too in case of previous failure).
Furthermore, the genuine boot loader have some conception to achive a nice updateable system. Therefore it is important what is it stored in the flash, because the bootloader handles multiple partitions, and try to load the latest partition... (Probably this is not an issue here, but good to know).
Yesterday I did tried to run / flash to your code to my boards, and it was running. I mean it could be run here, but I was able to fckup the process if I does something as I intended to test the unhandled failure cases...
I suggest to start with a clean flash content using xflash utility. To do this, probably you need the above v1.1 workaround if you own that board. (if the xflash does not finish success) And some --verbose option could be helpful on each step, to recognise what happened.
I agree, it would be nice to have a step-by-step documentation for the typical situations, or some collection of the all known cases...
-
colin
- Experienced Member
- Posts: 74
- Joined: Mon Dec 16, 2013 12:14 pm
Hi Hegt
It appears the problem lies with the use of node id names (Node Id="SLICE_0") rather than numerical values Node Id="0" within your XN file. I have raised an internal bug to have this issue addressed in the tools. In the mean time I have attached an XN that uses numerical values that will allow you to boot your device from flash.
Best Wishes,
Colin
It appears the problem lies with the use of node id names (Node Id="SLICE_0") rather than numerical values Node Id="0" within your XN file. I have raised an internal bug to have this issue addressed in the tools. In the mean time I have attached an XN that uses numerical values that will allow you to boot your device from flash.
Best Wishes,
Colin
You do not have the required permissions to view the files attached to this post.
-
myndideal
- Active Member
- Posts: 59
- Joined: Thu May 05, 2011 10:00 pm
- Location: Budapest
Hmm. Iam using alphanumeric node ids in my xn files, and it's compiling with 14.0.3, there's no problem at all with flashing...
Is this problem relating to the latest 14.0.4 only ?
Is this problem relating to the latest 14.0.4 only ?
-
colin
- Experienced Member
- Posts: 74
- Joined: Mon Dec 16, 2013 12:14 pm
It's a problem that can arise across all current versions of tools 14. It relates to the algorithm the tools use for generating the routing tables and ids used during the boot process. Using alphanumeric names can generate routing tables that are different to those generated with numeric names and whilst these tables are valid, can cause a very specific issue when booting an L2 network. It will not necessarily manifest itself with all alpha-numeric L2 networks.
-
hegt
- Member++
- Posts: 19
- Joined: Wed Sep 17, 2014 1:20 pm
Hey thank you colin! The new XN file you posted works for me.