broken startKIT - first stage multi-node boot failed

All technical discussions and projects around startKIT
User avatar
alfanick
Member
Posts: 12
Joined: Sat Jun 21, 2014 8:01 pm
Contact:

broken startKIT - first stage multi-node boot failed

Post by alfanick »

Hi,
this is my first post here, so hello everyone and thank you in advance for any help! :)

I've been enjoying my startKIT for some time now. Actually, I'm a big fan of Xmos technology. Me and my friend are developing self-balancing robot - hardware and mechanics are done already, basic software should be easy to write (pic here - http://cl.ly/image/1t0H2d1z213f) - we thought of neural networks, however deadline forces us to write PID.

Anyway, out of the nowhere, we started getting "xrun: First stage multi-node boot failed, please check XN file and Xmos link connectivity". We're not using xTimeComposer IDE (just vim + xmake/xrun/xflash), however using the IDE results the same error. I guess something with SPI flash is broken, but I'm not sure ;) I've done some googling, however, nothing seems to be related or working (tried pulling CS to high, still xrun doesn't work). Xmos seems to be alive - xrun -l list device correctly, xrun --dump-state-no-xe dumps registers, connection is alive. However nothing can't be flashed or run (yet old flashed code is still programmed on the flash).

So... Is it permanent hardware flaw or there is some way to debug it or solve? Any help accepted :D

Best wishes from Poland
Amadeusz (& Piotr)


TMentink
Junior Member
Posts: 7
Joined: Sat Apr 19, 2014 7:52 pm

Post by TMentink »

Hi,

I had some similar problems, try this:
  • Disconnect startkit from usb cable and any power supply.
  • Connect CS pin from spi flash (pin 1) to 3.3V from header J6 pin 4.
  • Keep CS pin connected and power the xmos from usb port.
  • Wait until the 9 leds are glowing on and off
  • Flash Startkit with the new program
  • Problem should be resolved :D
User avatar
alfanick
Member
Posts: 12
Joined: Sat Jun 21, 2014 8:01 pm
Contact:

Post by alfanick »

TMentink wrote:Hi,

I had some similar problems, try this:
  • Disconnect startkit from usb cable and any power supply.
  • Connect CS pin from spi flash (pin 1) to 3.3V from header J6 pin 4.
  • Keep CS pin connected and power the xmos from usb port.
  • Wait until the 9 leds are glowing on and off
  • Flash Startkit with the new program
  • Problem should be resolved :D
Awesome! Thank you very much :) It does work now!
User avatar
uc69
Member
Posts: 13
Joined: Thu Jan 04, 2018 8:34 pm

Post by uc69 »

Hello,
Sorry to revive this old case but I just encounter the same trouble "xrun: First stage multi-node boot failed, please check XN file and Xmos link connectivity".
The above recipe works BUT I have to do it each time I need to reflash !?
I tried to reflash the official examples of the starter kit, tried different USB cables, but same problem.
What is the root cause of this trouble ? Cant it be solved/repaired permanently ? The starter kit was on my desk, i did not touch it or did anything else when it happened, I was just modifying examples
...I'm going to solder a wire to pin 1 of the flash - or scrap the starter kit but it now seems out of stock everywhere ! Don't know if it will be available again ?
My experience with XMOS was very short, less than 20 reflashs !
Thanks,
J.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Not sure if you need to buy another kit...yet but Element14 (Singapore) is showing some stock so they can likely transfer to your local office:

http://sg.element14.com/xmos/xk-stk-a8d ... B-OCTOPART

Try the following:

1) Use your trick to allow for the StartKit to boot by forcing the SPI flash to be inactive. Remove the wire jumper so the SPI flash can be accessed normally.

2) Then dosshell (CMD) to run the XMOS Command Shell tool and type in:

xflash <ENTER> to confirm it is working

xflash --verbose --erase-all <ENTER>

then unplug the kit from your USB port -> wait 20-30 seconds -> dock again and attempt to use.

Guessing that XMOS is working on a StartKit for the XCORE-200 series. Wish XMOS would be more open about the EOL of parts, tools and resolutions.
User avatar
uc69
Member
Posts: 13
Joined: Thu Jan 04, 2018 8:34 pm

Post by uc69 »

Hello mon2,
I tried your recipe but xflash refuses the target "name" (tried '0', 'L', L0', 'L[0]', 'startKIT', etc.)
So, I still need this pin 1 voltage + usb disconnect - reconnect to be able to run a new program...
Tried on 2 different workstations, I'm now on Linux with the problem still present but the usb discon-recon is faster than in Windows (10) because for everything
discon-recon, Windows triggers the XMOS device driver (re) installation, everytime 20-30 long seconds to wait !

./xflash --list

Available XMOS Devices
----------------------

ID Name Adapter ID Devices
-- ---- ---------- -------
0 XMOS startKIT 0xfufAhZEHxii L[0]

root@4770K:/opt/XMOS/xTIMEcomposer/Community_14.3.2/bin# ./xflash --verbose --erase-all --target L[0]
XFlash_Options::ListDevices : xgdb --batch -q --ex listdevices devl-6e0d1ce4
XFlash::DoXFlash
Error: F03089 When multiple upgrade images and no global factory image is specified a target must be specified with --target.
root@4770K:/opt/XMOS/xTIMEcomposer/Community_14.3.2/bin#

Is this problem could be linked also to the strange behaviour I now have in https://www.xcore.com/viewtopic.php?f=3&t=6304 ?
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Try:

./xflash --verbose --erase-all --target startkit.xn ; and post your verbose output

Another idea, once the breathing LED demo loads due to bypass of the SPI flash, can you use the xTimeComposer tools to flash a different program? That is, do not worry about the CLI (command line interface) but try to do the same task using the tools.

Please post your results.
User avatar
uc69
Member
Posts: 13
Joined: Thu Jan 04, 2018 8:34 pm

Post by uc69 »

Here there are:
jea@4770K:/opt/XMOS/xTIMEcomposer/Community_14.3.2/bin$ ./xflash --verbose --erase-all --target startkit.xn
XFlash_Options::ListDevices : xgdb --batch -q --ex listdevices devl-179bbf6a
XFlash::DoXFlash
Error: F03089 When multiple upgrade images and no global factory image is specified a target must be specified with --target.

with 'STARTKIT.xn' instead of 'startkit.xn' AND the 'STARTKIT.xn' file copied from /opt/XMOS/xTIMEcomposer/Community_14.3.2/targets/STARTKIT to the same dir as xflash it seems to work:
jea@4770K:/opt/XMOS/xTIMEcomposer/Community_14.3.2/bin$ ./xflash --verbose --erase-all --target STARTKIT
XFlash_Options::ListDevices : xgdb --batch -q --ex listdevices devl-beb8376c
XFlash::DoXFlash
XFlash::DoReadWriteErase
XFlash_Programmer_Erase_NoChan::DoErase
XFlash_Programmer_Erase_NoChan::IssueCompileCommand
xcc -w -Xmapper --dontenablesodlinks -Xmapper --nochaninit -Xmapper --noinitialtidy -Xmapper --bootstyle=forsim -x xn "/opt/XMOS/xTIMEcomposer/Community_14.3.2/targets/STARTKIT/STARTKIT.xn" -O2 -lflash -D xnPORT_SPI_MISO0=PORT_SPI_MISO -D xnPORT_SPI_SS0=PORT_SPI_SS -D xnPORT_SPI_CLK0=PORT_SPI_CLK -D xnPORT_SPI_MOSI0=PORT_SPI_MOSI -x xc "fe-89adfc79" -o "fe-4e71cceb"
XFlash_Utils::BuildRunCommand : xrun --io fe-4e71cceb


So, again, even after doing the above manipulations (xflash, flash from xTime), if I try to- run or flash the prog, I still get "xrun: First stage multi-node boot failed, please check XN file and Xmos link connectivity" !

and yes, I can flash from xTimeComp (see attach), it was always the case, but then the board is locked, I need to:
1) reapply the 3.3 V on pin 1
2) disconnect - reconnect the USB cable
to be able either to do 'Run' or 'Flash'.

Thanks, J.
Attachments
flash.png
(216.8 KiB) Not downloaded yet
flash.png
(216.8 KiB) Not downloaded yet
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Wow. You need a priest. Just now, wasted 30 minutes to get my StartKit working on Windows 7 64 bit box - pure krapware. However, we are guilty of having every kit on the planet (St, Nordic, Silabs, TI, Cypress) - all are installed on this box.

Me against the StartKit:

https://www.youtube.com/watch?v=-rjHSZfltL0

"Why you are not installing on my Win7 64 box, why why why?"


The permutation that just worked to allow me to detect by kit (which always worked in the past) was to use the BLUE USB port and not through the internal motherboard hub controller. These are only work arounds and believe the USB IP is broken. Anyways, it is now being detected on my box. Guessing that the StartKit demands the use of a USB 2.0 HS port which does not say a lot of the motherboard I have - this day an age, USB FS only ports??

Perhaps consider to just replace the SMD flash memory device but be sure to source the same p/n from Arrow or Digikey. It is an interesting challenge you have and believe we too faced this issue.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Ok, after eating an apple, more energy and more ideas...

Believe that your flash IC is not totally erased when you perform the --erase-all. Why? This will be the case if the flash IC contains the boot code for multi-node firmware. That is, the initial portion of the flash device is write protected and according to the flash datasheet, the CHIP_ER command will fail.
xmos_flash_protected.png
(101.37 KiB) Not downloaded yet
xmos_flash_protected.png
(101.37 KiB) Not downloaded yet
Please try to the following to read out the contents of your flash device:

Code: Select all

xflash --verbose --read-all -o first_dump.bin  --target startkit.xn
this should read out the entire contents of the flash device which you can review using any binary file editor (there are many on Windows for free)

then

Code: Select all

xflash --verbose --erase-all --target startkit.xn 
then again

Code: Select all

xflash --verbose --read-all -o second_dump.bin  --target startkit.xn 
Now, do a binary compare of the two .bin files. On Windows, dosshell:

Code: Select all

fc /b first_dump.bin second_dump.bin


What is the result? You should load in the second_dump.bin into a binary file editor to verify that the entire flash is full of 0xFF (FFh).

https://www.hhdsoftware.com/free-hex-editor

In theory, if the erase-all works, then the second_dump.bin file should be full of 0xFF (FFh) value only. My guess is that you will not see 0xFF throught out the flash dump due to the write protected sectors inside the flash. Once you can confirm this, it should be possible to throw some specific SPI commands to remove the write protection OFF the SPI flash to "virginize" the memory device.

https://www.howtogeek.com/206123/how-to ... nd-prompt/
Post Reply