Multiple Masters on SPI

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 ) to control a mux like a 74F257A.

Block diagram is at:

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.
Reply to
sms
Loading thread data ...

Den onsdag den 23. oktober 2013 23.12.38 UTC+2 skrev sms:

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

Reply to
Lasse Langwadt Christensen

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.

Reply to
sms

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.

Reply to
edward.ming.lee

Use two independent SPI memories.

Reply to
Vladimir Vassilevsky

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

Reply to
Lasse Langwadt Christensen

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.

Reply to
sms

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
Reply to
Joe Chisolm

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.

Reply to
sms

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
Reply to
Joe Chisolm

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

--
?? 100% natural 

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply to
Jasen Betts

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

Reply to
Martin Riddle

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.