Forums

Multiple Masters on SPI

Started by sms October 23, 2013
I'm working on a design where a Cortex M3 writes data to an SPI Flash 
memory. The issue is that I have a data acquisition device that also 
needs to read the SPI Flash. Both devices can only be SPI masters. The 
UART on the Cortex M3 is being used for something else and I2C is too 
slow. Essentially we're trying to make the SPI Flash into a dual-port 
SPI Flash with external logic.

In searching for a solution I've seen that a lot of people have had a 
similar issue with SPI, needing multiple masters to be able to read from 
slave devices, which is not something SPI was designed for.

I'm trying to figure a way to use the I2C bus from the Cortex M3 to 
control some sort of multiplexer that can disconnect the Cortex M3 from 
the SPI bus and allow the data acquisition device to take over the bus. 
We have no GPIO pins available on the Cortex M3 to use for handshaking 
or to control the multiplexer.

We're thinking of using a I2C port expander (TCA9554 
<http://www.ti.com/product/tca9554>) to control a mux like a 74F257A.

Block diagram is at: <http://oi40.tinypic.com/34qvexl.jpg>

If there are any SPI experts out there willing to take a look at this 
provide some feedback it would be appreciated.

Again, the considerations are:
1. We have no GPIOs still available.
2. The I2C bus is too slow to use for reading the contents of the Flash.
3. The UART is being used for something else.
4. We want to read the Flash from both the Cortex M3's SPI port and from 
an external DAQ's SPI port.
5. The Cortex M3 and the DAQ can only be SPI masters.
Den onsdag den 23. oktober 2013 23.12.38 UTC+2 skrev sms:
> I'm working on a design where a Cortex M3 writes data to an SPI Flash > > memory. The issue is that I have a data acquisition device that also > > needs to read the SPI Flash. Both devices can only be SPI masters. The > > UART on the Cortex M3 is being used for something else and I2C is too > > slow. Essentially we're trying to make the SPI Flash into a dual-port > > SPI Flash with external logic. > > > > In searching for a solution I've seen that a lot of people have had a > > similar issue with SPI, needing multiple masters to be able to read from > > slave devices, which is not something SPI was designed for. > > > > I'm trying to figure a way to use the I2C bus from the Cortex M3 to > > control some sort of multiplexer that can disconnect the Cortex M3 from > > the SPI bus and allow the data acquisition device to take over the bus. > > We have no GPIO pins available on the Cortex M3 to use for handshaking > > or to control the multiplexer. > > > > We're thinking of using a I2C port expander (TCA9554 > > <http://www.ti.com/product/tca9554>) to control a mux like a 74F257A. > > > > Block diagram is at: <http://oi40.tinypic.com/34qvexl.jpg> > > > > If there are any SPI experts out there willing to take a look at this > > provide some feedback it would be appreciated. > > > > Again, the considerations are: > > 1. We have no GPIOs still available. > > 2. The I2C bus is too slow to use for reading the contents of the Flash. > > 3. The UART is being used for something else. > > 4. We want to read the Flash from both the Cortex M3's SPI port and from > > an external DAQ's SPI port. > > 5. The Cortex M3 and the DAQ can only be SPI masters.
tristate (with pullup on ce when you don't need the spi bus), why would you need any extra hardware? if CE is high the device doesn't care, if you are not trying to clock out data the master doesn't care -Lasse
On 10/23/2013 3:34 PM, Lasse Langwadt Christensen wrote:

<snip>

> tristate (with pullup on ce when you don't need the spi bus), why would > you need any extra hardware? > > if CE is high the device doesn't care, if you are not trying to clock out > data the master doesn't care
Tri-stating actually takes more hardware than using a MUX because we'd have to tri-state two SPI Clocks, two SPI chip selects, and two SPI data outputs. Unfortunately most of the pins out of the processor are not open-drain, including the ones for the SPI interface.
> 5. The Cortex M3 and the DAQ can only be SPI masters.
You can do a SPI slave in software, if the data rate is low enough. Have your DAQ SPI to M3 first, then M3 to flash.
On 10/23/2013 4:12 PM, sms wrote:
> I'm working on a design where a Cortex M3 writes data to an SPI Flash > memory. The issue is that I have a data acquisition device that also > needs to read the SPI Flash. Both devices can only be SPI masters. The > UART on the Cortex M3 is being used for something else and I2C is too > slow. Essentially we're trying to make the SPI Flash into a dual-port > SPI Flash with external logic.
Use two independent SPI memories.
Den torsdag den 24. oktober 2013 01.59.48 UTC+2 skrev sms:
> On 10/23/2013 3:34 PM, Lasse Langwadt Christensen wrote: > > > > <snip> > > > > > tristate (with pullup on ce when you don't need the spi bus), why would > > > you need any extra hardware? > > > > > > if CE is high the device doesn't care, if you are not trying to clock out > > > data the master doesn't care > > > > Tri-stating actually takes more hardware than using a MUX because we'd > > have to tri-state two SPI Clocks, two SPI chip selects, and two SPI data > > outputs. Unfortunately most of the pins out of the processor are not > > open-drain, including the ones for the SPI interface.
a pullup and diodes could do that but why not just configure the SPI pins to gpio inputs when you don't need them? -Lasse
On 10/24/2013 2:20 AM, Lasse Langwadt Christensen wrote:
> Den torsdag den 24. oktober 2013 01.59.48 UTC+2 skrev sms: >> On 10/23/2013 3:34 PM, Lasse Langwadt Christensen wrote: >> >> >> >> <snip> >> >> >> >>> tristate (with pullup on ce when you don't need the spi bus), why would >> >>> you need any extra hardware? >> >>> >> >>> if CE is high the device doesn't care, if you are not trying to clock out >> >>> data the master doesn't care >> >> >> >> Tri-stating actually takes more hardware than using a MUX because we'd >> >> have to tri-state two SPI Clocks, two SPI chip selects, and two SPI data >> >> outputs. Unfortunately most of the pins out of the processor are not >> >> open-drain, including the ones for the SPI interface. > > a pullup and diodes could do that > > but why not just configure the SPI pins to gpio inputs when you don't need them?
Yes, that's a good idea. It will save the mux chip. I have to ask one of software people if they are willing to continually reprogram the GPIO direction for the SPI CLK, SPI CS, and SPI Data, on the processor and on the DAQ.
On Wed, 23 Oct 2013 14:12:38 -0700, sms wrote:

> I'm working on a design where a Cortex M3 writes data to an SPI Flash > memory. The issue is that I have a data acquisition device that also > needs to read the SPI Flash. Both devices can only be SPI masters. The > UART on the Cortex M3 is being used for something else and I2C is too > slow. Essentially we're trying to make the SPI Flash into a dual-port > SPI Flash with external logic. > > In searching for a solution I've seen that a lot of people have had a > similar issue with SPI, needing multiple masters to be able to read from > slave devices, which is not something SPI was designed for. > > I'm trying to figure a way to use the I2C bus from the Cortex M3 to > control some sort of multiplexer that can disconnect the Cortex M3 from > the SPI bus and allow the data acquisition device to take over the bus. > We have no GPIO pins available on the Cortex M3 to use for handshaking > or to control the multiplexer. > > We're thinking of using a I2C port expander (TCA9554 > <http://www.ti.com/product/tca9554>) to control a mux like a 74F257A. > > Block diagram is at: <http://oi40.tinypic.com/34qvexl.jpg> > > If there are any SPI experts out there willing to take a look at this > provide some feedback it would be appreciated. > > Again, the considerations are: > 1. We have no GPIOs still available. > 2. The I2C bus is too slow to use for reading the contents of the Flash. > 3. The UART is being used for something else. 4. We want to read the > Flash from both the Cortex M3's SPI port and from an external DAQ's SPI > port. > 5. The Cortex M3 and the DAQ can only be SPI masters.
What type of "Cortex M3"? Lot of variants. Depending on the part, turn off the SPI function with the M3 pin select and set the pins to input. Turn it back on and initialize when you need to talk to the flash. This of course depends on you having a way to tell the DAQ to shut up and leave the bus idle. -- Chisolm Republic of Texas
On 10/24/2013 10:22 PM, Joe Chisolm wrote:

<snip>

> Depending on the part, turn off the SPI function with the M3 pin > select and set the pins to input. Turn it back on and initialize when > you need to talk to the flash. This of course depends on you having > a way to tell the DAQ to shut up and leave the bus idle.
NXP LPC1347. You're right, we can switch the pins to inputs. We do have handshaking between the two devices to prevent both from trying to use the SPI bus at the same time. The final product won't need this type of thing, but for development we need this capability.
On Thu, 24 Oct 2013 22:37:41 -0700, sms wrote:

> On 10/24/2013 10:22 PM, Joe Chisolm wrote: > > <snip> > >> Depending on the part, turn off the SPI function with the M3 pin select >> and set the pins to input. Turn it back on and initialize when you >> need to talk to the flash. This of course depends on you having a way >> to tell the DAQ to shut up and leave the bus idle. > > NXP LPC1347. You're right, we can switch the pins to inputs. We do have > handshaking between the two devices to prevent both from trying to use > the SPI bus at the same time. > > The final product won't need this type of thing, but for development we > need this capability.
I would have to look but it is maybe 10 lines of code to init the ssp block. This will be a small fraction of your total write time. The read (if not full sector write), sector erase and write are going to dominate. You should be able to flip back just by setting the PINSEL function. Watch for any pull up or pull down issues. -- Chisolm Republic of Texas