SPI with multiple microcontrollers

Kinda a slim chance this one will work for you, but if both micros don't 
need to be running at the same time, some micros will high Z their pins when 
powered down. Have the second micro control power to the first, then it can 
safely access the SPI bus, and then software high Z it's pins when the first 
micro is running.

Just a crazy thought.

Thomas

"Alexander Becher" <abecher@i4.informatik.rwth-aachen.de> wrote in message 
news:3j7ggvFng6c5U1@news.dfncis.de...
> Hello everyone,
>
> I am facing the following situation: I have a microcontroller (e.g.
> Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory chip
> (e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to enable a
> second microcontroller to access the flash memory.
>
> The central question in this regard is: Can I add this second
> microcontroller to the bus without changing the software on the first
> microcontroller or the wiring to it? Or do I need some support for this
> configuration in the first uC?
>
> Obviously, I used Google with the wrong search terms, so I'm trying my
> luck here. I'd appreciate any replies.
>
> Regards
> Alexander Becher
> 

"Thomas Magma" <somewhere@overtherainbow.com> wrote in message 
news:QJxze.1906260$6l.386874@pd7tw2no...
>
> 2) The second micro would control the tri-state of the first and take 
> control of the SPI. It depends on his specific application whether this 
> would be a viable solution.
>

Not a good approach. If the second controller tri-states the signal lines 
while the first controller has an operation in progress then you'd end up 
with 'unpredictable results' at best.

I would go for one of these approaches:

1. If the first controller doesn't need to run all the time, tie the second 
controller to the reset line of the first controller. When the second 
controller wants access, place the first controller in reset state. Most 
controllers will place their outputs in Hi-Z mode when in reset state.

2. Make changes to the first controller hardware/software. Tie an 'access 
request' line from the second controller to an input of the first 
controller. When the first controller thinks it's safe, have it tri-state 
it's SPI lines and signal 'access granted' to the second controller via 
another line. Full handshake, and entirely safe.

Rob

I wrote:
> I am facing the following situation: I have a microcontroller (e.g.
> Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory
> chip (e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to
> enable a second microcontroller to access the flash memory.
> 
> The central question in this regard is: Can I add this second
> microcontroller to the bus without changing the software on the first
> microcontroller or the wiring to it? Or do I need some support for
> this configuration in the first uC?

Many thanks to everyone who replied so far. I'll try to give some more
background on the scenario.

This work is part of a security analysis of an existing product.
Therefore, the software on the 1st uC is fixed. The wiring can only be
changed by tampering with the product while it is fielded, e.g. by
using a soldering iron and assorted accessories. At the same time, the
2nd uC used to carry out the attack is not limited to any particular
class of products and might even be a laptop computer.

If I were designing a new product, it would certainly be easy to go for
a different bus system with true multi-master capability, or
alternatively to implement some software handshake between the two uCs. 

However, in this scenario, this is not possible. From what I've gathered
from the replies, I see three options:

(a) Emulate the bus in the second uC. Connect the 1st uC to the second
uC instead of the SPI bus, and make the 2nd uC a slave on the SPI
connection to the 1st uC and a master on the bus to the flash.

The advantage of this approach is that operation of the 1st uC would not
be interrupted, except for some timing delays due to the emulation.

The disadvantage is that the wiring still needs to be changed, if I
understood correctly, and that the emulation needs to be written in the
first place. Also, the flash is not the only device on the SPI bus (the
lines are shared with an RF transceiver), which would make this even
more complicated.

(b) Power down the 1st uC or keep it in reset state while the 2nd uC is
accessing the bus.

Advantage: Simple software for 2nd uC.

Disadvantage: Regular operation is interrupted. If at all possible, I
would like to avoid this, as this might lead to detection of the
attack.

(c) Use a tri-state buffer on the SPI pins of the 1st uC.

Advantage: 1st uC can be disconnected by the 2nd uC without resetting
it, meaning that the interruption will probably not be noticed unless
the 1st uC tries to access the SPI bus while it is disconnected.

Disadvantage: Still needs a change in the wiring.

If anybody still has comments, I'd be glad to hear them.

Regards
Alexander Becher

On Thu, 14 Jul 2005 14:16:46 +0200, Alexander Becher
<abecher@i4.informatik.rwth-aachen.de> wrote:

>I wrote:
>> I am facing the following situation: I have a microcontroller (e.g.
>> Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory
>> chip (e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to
>> enable a second microcontroller to access the flash memory.
>> 
>> The central question in this regard is: Can I add this second
>> microcontroller to the bus without changing the software on the first
>> microcontroller or the wiring to it? Or do I need some support for
>> this configuration in the first uC?
>
>Many thanks to everyone who replied so far. I'll try to give some more
>background on the scenario.
>
>This work is part of a security analysis of an existing product.
>Therefore, the software on the 1st uC is fixed. The wiring can only be
>changed by tampering with the product while it is fielded, e.g. by
>using a soldering iron and assorted accessories. At the same time, the
>2nd uC used to carry out the attack is not limited to any particular
>class of products and might even be a laptop computer.
>
>If I were designing a new product, it would certainly be easy to go for
>a different bus system with true multi-master capability, or
>alternatively to implement some software handshake between the two uCs. 
>
>However, in this scenario, this is not possible. From what I've gathered
>from the replies, I see three options:
>
>(a) Emulate the bus in the second uC. Connect the 1st uC to the second
>uC instead of the SPI bus, and make the 2nd uC a slave on the SPI
>connection to the 1st uC and a master on the bus to the flash.
>
>The advantage of this approach is that operation of the 1st uC would not
>be interrupted, except for some timing delays due to the emulation.
>
>The disadvantage is that the wiring still needs to be changed, if I
>understood correctly, and that the emulation needs to be written in the
>first place. Also, the flash is not the only device on the SPI bus (the
>lines are shared with an RF transceiver), which would make this even
>more complicated.
>
>(b) Power down the 1st uC or keep it in reset state while the 2nd uC is
>accessing the bus.
>
>Advantage: Simple software for 2nd uC.
>
>Disadvantage: Regular operation is interrupted. If at all possible, I
>would like to avoid this, as this might lead to detection of the
>attack.
>
>(c) Use a tri-state buffer on the SPI pins of the 1st uC.
>
>Advantage: 1st uC can be disconnected by the 2nd uC without resetting
>it, meaning that the interruption will probably not be noticed unless
>the 1st uC tries to access the SPI bus while it is disconnected.
>
>Disadvantage: Still needs a change in the wiring.
>
>If anybody still has comments, I'd be glad to hear them.
>
>Regards
>Alexander Becher

Well, you could use a SPI bus analyzer and sniff the SPI bus. This
would allow you to see everything read or written by the master,
without it knowing you are watching.

This would not allow you to write to anything on the SPI bus, or read
anything the master did not read. In this senario you are just a
passive wiretap. This can be very helpful in debugging a SPI bus, I
don't know if it will help with your app.

Regards ~Steve
There is no "x" in my email address.