How to disable SPI Bus on slicekit Core Board ?

[140dB]

Hello All,

I am looking to switch the Spi bus from the on board flash located on the General Purpose Core board to the GPIO pins broken out on the hardware. I know the core board hardware guide states that X0D42 nd X0D43 need a special sequence of high's and low's to disable the on board flash and switch to the header pins located on the triange slot. 

My issue comes when I am running the AVB-DC application which defines pins X0D34 through X0D39 for the Audio PLL slice. If these pins are defined then the port neccessary to switch the X0D42 and X0D43 are off limits right? 

If I understand correctly ports cannot overlap once defined? I want to be able to switch from GPIO to flash "on the fly" by enabling and disabling based on what the application needs at any given point in time. 

As stated in the dialog below the pins P8D6 and P8D7 manipulate the hardware logic on the core board. Can these pins be written to manually without having to write to all the ports at once even with the AVB-DC application defining the lower port numbers?

This seems kind of silly to me for two reasons:

1) why would such a commonly used bus be locked into only talking to an on board flash chip 

2) Xmos is supposed to be the "microcontroller that does what you want" chip. 

I want to use one spi bus for my application to talk to the on board flash and switch to external GPIO for my application. How can I do this when the pins are constrained as stated above? 

Here is the Slice Kit harware explination of the flash Enable/Disable scheme:

To allow re-use of the SPI boot pins (ports 1A, 1B, 1C, 1D) as signal I/O pins for the Star slot, a latched bus switch is used which connects the xCORE SPI pins to either the SPI Flash or to the sliceCARD slots. The switch is controlled by X0D42 and X0D43 (P8D6 and P8D7 on Tile 0 - on the Triangle slot). Once the device has booted, X0D43 is used to enable or disable the SPI interface, X0D42 should then transition from low to high to latch the selection. The SPI selection state is maintained until the system is reset.

[mon2]

My issue comes when I am running the AVB-DC application which defines pins X0D34 through X0D39 for the Audio PLL slice. If these pins are defined then the port neccessary to switch the X0D42 and X0D43 are off limits right?

X0D34..X0D39 are 1B (single bit ports) which have the highest priority. Assignment is from LEFT to RIGHT in the port priority.

Use of X0D34..X0D39 will remove access to the same overlapped pins relating to P8D0..P8D3 so P8D0..P8D3 are no longer available via the 8B group.

However, the remaining P8D4..P8D7 are available for your use which will support the required X0D42 and X0D43 SPI MUX pins.

Please see attached for a diagram showing the same details.

============

As an extreme plan B or C, you can consider to map a few free pins to an external SPI flash memory. We have done this in the past and standard SPI flash support is relatively straight forward. We are working on a SPI Flash / QUAD SPI Flash / SD Card flash support using an external slice board. If you have a free slice socket available, that may be an option. Will post more details upon the completion of the new slice (ETA is a few weeks out).



 



 

 

[mon2]

"on stdcore[0] : out port external_spi XS1_PORT_8D" and then write the proper hex value that will toggle the pins?

Correct. See below for some examples.

Keep in mind that XS1_PORT_8D port is grouped so you are obligated to use all port pins in this group in the same direction. If output, all port pins this block will be in output mode and respectively if input, then all in input mode.

It is possible to use the port pins in I/O mode (as a group) - see the documentation on PORTS on this and XMOS website. Also the IP relating to FLASH memory use offers some code examples on how 4 bits are able to R/W to SD CARD code.

The XMOS devices are hyper I/O (aka bit banging), low latency processors. Varying only with your applied IP, the code can morph to support SPI, QUAD SPI, I2C, Ethernet, USB, UART, etc. In many cases, you can simply bit-bang as show below but the XMOS language and architecture allows for much more to gain higher data rates including the option to buffer your data, clock in / out your data with precision based on each single clock cycle. The clock cycle can be mapped internally or via the use of an external clock source (to achieve skewed data rates which may be more accurate for your application). As with all logic, there is a limitation on the I/O speeds and believe it is 60 Mhz for the XMOS XS1 architecture.

 

https://www.xmos.com/zh/download/public ... 73A%29.pdf

 

//::Port configuration
out port external_spi=XS1_PORT_8D;

// next set of declarations have priority since 1B wide
// and will remove access to larger ports that overlap on the right side of port table
out port my_single_bit_port_M = XS1_PORT_1M;
out port my_single_bit_port_N = XS1_PORT_1N;
out port my_single_bit_port_O = XS1_PORT_1O;
out port my_single_bit_port_P = XS1_PORT_1P;

 //::Main start
void main(void)
{

while(1)
{
        external_spi <: 0x80; // X0D43 = HIGH, rest of this 8B port low
        external_spi <: 0x40; // X0D42 = HIGH, rest of this 8B port low
        external_spi <: 0x20; // X0D41 = HIGH, rest of this 8B port low
        external_spi <: 0x10; // X0D40 = HIGH, rest of this 8B port low

        external_spi <: 0x01; // will not access X0D36 since assigned to 1B port P1M0
        external_spi <: 0x02; // will not access X0D37 since assigned to 1B port P1N0
        external_spi <: 0x04; // will not access X0D38 since assigned to 1B port P1O0
        external_spi <: 0x08; // will not access X0D39 since assigned to 1B port P1P0
}

}

//::Main