SliceKit x200 boot from SPI Slave

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
Junior Member
Posts: 6
Joined: Tue Oct 17, 2017 4:47 pm

SliceKit x200 boot from SPI Slave

Postby shdrmr » Tue Oct 17, 2017 5:01 pm

Hey guys, I am fairly new to the XMOS world and for our application, we would like to remotely upgrade the firmware using SPI. The SPI Master in this case is a raspberry pi. I have followed specific to dot instructions from AN00238 about compiling an image and the bootloader. I have also ensured that the SPI is in the correct mode (mode3/LSB fist/ 100Khz) using an oscilloscope. These are the problems I have encountered.

The application says that X0D05 should be high for SPI slave mode. I am successfully seeing that it is in SPI Slave boot mode (xrun dump state shows tile 0 is at 0xfff00734), but to achieve this, I had to set X0D49 to high so that the digital latch connects X0D05 to the jumper expansion rather than the QSPI flash. (WHY CANT THEY JUST GIVE SOME GODDAMN PINS). However I am still not able to transfer the image.

1.My question is what is the procedure for this board. Why is it so ambiguous or hardly any instructions exist.
2. How does SPI slave boot work. Does it wait for SS to go low , then transfer and then once SS is high it "knows" that the program has been transferred??
3 IS there any modifications to XN file. If so where are the INSTRUCTIONS
4. Are the pins X0D00, X0D11 and X0D10 on the expansion header even connected to the Xcore.
5. How to verify that the transfer even took place (I am not talking about blinky blinky LED) but actual transfer validation.
Posts: 22
Joined: Fri Aug 12, 2016 6:13 pm

Postby plex » Wed Oct 18, 2017 12:19 pm

There is no SPI Slave mode. If X0D05 is high then device will boot from link. The links do not use spi communications. To boot from the flash X0D05 and X0D06 must be low.
Making the xmos boot through an xmos link from the RPi, having the PRi behave as an xmos master will be very difficult if not impossible.
Some info on the xmos links:

I am not really sure what you want to achieve so I will assume that you want to use the PRi to write directly to the boot flash so that the xmos can then boot from the image you have written.

Looking at the Slicekit X200 schematic, the boot flash spi pins are connected to the xmos through a multiplexer. During boot the connection is enabled to allow the xmos to read from flash and after boot you can set a pin to make the multiplexer disconnect the boot flash and connect the xmos pins to header connections so that they can be used as gpio.
So the boot flash spi pins are not directly connected to any of the headers meaning that you would have to solder in connections if you want to access this flash with the RPi. Another way might be to to bridge the pins of the multiplexer so that the flash spi lines always go to the headers (you will lose the capability to use these pins as gpio).
Please note that extending these lines could cause signal integrity problems.
After that is done and the RPi is connected you need to take care of 2 states
1. Normal operation: The RPi must not drive any of the spi signals to allow the xmos to boot correctly.
2. Firmware update:
Option a.The RPi must hold the xmos in reset(using the RST_N pin of the debug connector) and then read-write-verify the flash.
Option b. If you have kept the multiplexer functionality intact and only soldered additional wires from the boot flash to the RPi you can use the SPI_SEL_N control signal to force the multiplexer to disconnect the flash from the xmos and do your read-write-verify. The xmos will not stop working and the new firmware will be used on the next boot.

There is alternative way that does not require any modification to the board.
Create a firmware update application for the xmos that gets data from gpio which you can then connect to the RPi via spi,serial or i2c. Program this application to the xmos using the xtag as a factory image. Then the RPi can add upgrade firmware images by communicating with this app.
This method can also be used in production and utilise the AES encryption capability of the XMOS. This firmware update app must also be embedded in your normal firmware image as when there is a valid upgrade image the xmos will boot directly to it and bypass the factory image.
To make sure that the device cannot be bricked you will have to make it dual boot(there is an xmos app note explaining how to do this) with control from a gpio connected to the RPi. This way the RPi can force the xmos to boot to the factory image.
Junior Member
Posts: 6
Joined: Tue Oct 17, 2017 4:47 pm

Postby shdrmr » Wed Oct 18, 2017 3:02 pm

Thanks for your reply. I am sorry I did not set my requirements straight.

The application uses the XU216-512-TQ128 connected to a Raspberry Pi (). It sends data back and forth using SPI and we have designed a PCB to do this. In the next iteration of the PCB, we would like to eliminate the use of QSPI flash. In other words my objective is, at boot, the XMOS should be in SPI slave mode (X0D06 = 0, X0D05 = 1, X0D04 = 0) and will receive the program through the SPI boot pins. Once the xmos receives it, it should boot up. The reason we are aiming for this, we would like to reduce footprint and well as cost. In the data sheet, they mention this possibility in page 17.

In order to not risk bricking the board, we are trying it on the slicekit 200. The data sheet of chip (xe216-512-fb236) also mentions spi slave boot is possible. Using application note AN00238 as an example, we tried to supply the boot image through SPI with no success.

1. If i am successful in establishing a connection between the SPI boot pins on the XMOS and the header, what is the procedure. I followed the same in AN00238, which are:
- compile the custom bootloader to get the required files.
- paste the files in the directory of my application makefile
- compile the application makefile adn convert to binary.
- convert binary to C header file using xxd command and use RPi to send the data.
The Slicekit x200 does not boot but when i dump state it it shows that it is waiting at 0xfff00734 - indicating that it is in SPI slave boot mode but it is still waiting?

2 In the data sheet page 18, they say
" If required, an SPI boot program can be burned into OTP that uses different pins". How exactly is this possible. This will give us the opportunity to choose any pin to load the image from.

Once again, I really appreciate your help since I am in a pickle now.
Posts: 22
Joined: Fri Aug 12, 2016 6:13 pm

Postby plex » Wed Oct 18, 2017 4:02 pm

My mistake as I had not read the datasheet for this device and based my knowledge on the devices that have embedded flash.
I understand better now.

From your first post it looks like you have the correct pins connected between the RPi and xmos.(X0D00 chip select(controlled from RPi),X0D10 clock(from RPi), X0D11 mosi(RPi data out)
You will need to make sure that the multiplexer U14 is forced to connect the X0D10 signal to the header and not the boot flash. To do that you need to set the SPI_SEL_N to high.

In AN00238 is states that SPI mode 0 is required and in your post you say that you are using mode3???

Apart from that and the fact that the master should send the data byte with LSB first which I think is taken care of in loader/generate_spi_slave_image command it seems to be straightforward.

To try answer your initial 5 questions:
2.Yes that is what the app note says. You need to wait 1ms after reset before staring the data transfer.
3. The app note says no but also mentions that you might want to remove references to spi/qspi.
4. X0D00 and X0D11 directly as shown in the schematic, X0D10 through multiplexer U14
5. There does not seem to be a way to verify besides having your application do something after booting that the RPi can see.

Please note that this slave boot method does not allow the following features that are available when booting from flash: compression, firmware upgrade, multiple application images, or encryption.
Junior Member
Posts: 6
Joined: Tue Oct 17, 2017 4:47 pm

Postby shdrmr » Wed Oct 18, 2017 4:13 pm


Yes you are right. I have soldered a pullup resistor to 3.3 V line to SPI_SEL_N (this line is exposed only in the XLINK debug up line and i soldered this to the JTAG adapter.) It is successful because the device wont be in SPI slave boot mode (tile 0 will be at address 0xfff00734) otherwise. When does the program boot? After the SS line is inverted?

Who is online

Users browsing this forum: No registered users and 52 guests