Multiple Masters on SPI

[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.

[Lasse Langwadt Christensen]

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

[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.

[edward....@gmail.com]

> 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.

[Vladimir Vassilevsky]

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.

[Lasse Langwadt Christensen]

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

[sms]

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.

[Joe Chisolm]

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

[sms]

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.

[Joe Chisolm]

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.

[Jasen Betts]

On 2013-10-23, sms <scharf...@geemail.com> 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.

You want synchronous read and write that dual port memory allows?


--
⚂⚃ 100% natural

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Martin Riddle]

On Thu, 24 Oct 2013 10:07:39 -0700, sms <scharf...@geemail.com>
wrote:

Have the M3 monitor the bus for inactivity, then allow it to write.
Sort of make it a slave, and give the DAQ device priority to avoid
collisions.

Cheers