SPI with multiple microcontrollers

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

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

You are only allowed a single master on SPI, so you will need to change the 
original.  Depending on the chips used you may cause problems for the 
original master if you bang on the clock line with another device.

You may need to let the master get the data that you want.  If you have a 
spare line you could set an I/O  bit to tell the master you need something.

Scott

Seems to me that you would have to high z the SPI interface on the original 
micro. You could do this in hardware with a tri-state buffer but this means 
changing the wiring, which is what you asked to avoid. However there are 
huge advantages to not changing the original software, based one how your 
company handles software control and documentation.

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:
> Seems to me that you would have to high z the SPI interface on the original 
> micro. You could do this in hardware with a tri-state buffer but this means 
> changing the wiring, which is what you asked to avoid. However there are 
> huge advantages to not changing the original software, based one how your 
> company handles software control and documentation.

Two comments:

1) If getting a software change filed into the configuration
management system is noticably harder than getting a hardware change
filed, then I would tend to claim you have a seriously broken CMS on
your hands (or you're using it very badly).

2) A hardware change alone almost certainly wouldn't help, anyway:
only the software will be in a position to know when to high-z those
pins.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

On 2005-07-08, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> Thomas Magma <somewhere@overtherainbow.com> wrote:

>> Seems to me that you would have to high z the SPI interface on
>> the original micro. You could do this in hardware with a
>> tri-state buffer but this means changing the wiring, which is
>> what you asked to avoid. However there are huge advantages to
>> not changing the original software, based one how your 
>> company handles software control and documentation.
>
> Two comments:
>
> 1) If getting a software change filed into the configuration
> management system is noticably harder than getting a hardware
> change filed, then I would tend to claim you have a seriously
> broken CMS on your hands (or you're using it very badly).

Perhaps he's trying to avoid forking the firmware that runs in
the old processor.

> 2) A hardware change alone almost certainly wouldn't help,
> anyway: only the software will be in a position to know when
> to high-z those pins.

Unless you gave the new processor control over the old
processor's buffers.  The new processor could then "disconnect"
the old one.   If the old processor tries to use the SPI bus
while it's disconnected let's hope the error handling in the
old SW is up to snuff. 

-- 
Grant Edwards                   grante             Yow!  Just imagine you're
                                  at               entering a state-of-the-art
                               visi.com            CAR WASH!!

Alexander Becher <abecher@i4.informatik.rwth-aachen.de> 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.

Plugging multi-master capability into an existing bus system that
isn't designed to support them is quite certainly impossible without
change to existing masters.  Think about it: how would your existing
master know that it may not touch the bus while the second one is
using it, if its designer never had reason to believe that such a
thing might happen?  

The thing's called the "master" because it owns the bus, and may do
with it whatever it wants, any time it wants.  There's no way you're
going to break it out of that attitude without breaking its package.

Therefore I suspect your best bet would be to seriously re-think the
goal: why do you want to do this, and what completely different ways
might exist to do it?

Second-best, implement a protocol on top of SPI to let the masters
hand over ownership of the bus from one to the other.  Token-passing
or regular "do you need the bus?" queries from the current master to
the dormant one would be among the obvious choices.  For this to work,
the masters also have to be able to act as SPI slaves.

Otherwise, you'll need physical intervention, i.e. the "ueber-master"
could have direct control over parts of the hardware of the secondary
master, so it can disable its transmitters or even disconnect it from
the lines completely.

Or just forget about SPI and use a protocol that's actually designed
for multi-master applications.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

"Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote in message 
news:3j7malFokhtlU3@news.dfncis.de...
> Thomas Magma <somewhere@overtherainbow.com> wrote:
>> Seems to me that you would have to high z the SPI interface on the 
>> original
>> micro. You could do this in hardware with a tri-state buffer but this 
>> means
>> changing the wiring, which is what you asked to avoid. However there are
>> huge advantages to not changing the original software, based one how your
>> company handles software control and documentation.
>
> Two comments:
>
> 1) If getting a software change filed into the configuration
> management system is noticably harder than getting a hardware change
> filed, then I would tend to claim you have a seriously broken CMS on
> your hands (or you're using it very badly).
>
> 2) A hardware change alone almost certainly wouldn't help, anyway:
> only the software will be in a position to know when to high-z those
> pins.
>
> -- 
> Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
> Even if all the snow were burnt, ashes would remain.

Two comments.

1) DO-178A or equivalent.
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.

I was just providing possible solutions to help in the thought process. 
Without knowing his specific application or hardware or the engineering 
quality procedures of his company, it's impossible to suggest the most 
effective method of implementation.

Thomas 

Grant Edwards <grante@visi.com> wrote:
> On 2005-07-08, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:

> Perhaps he's trying to avoid forking the firmware that runs in
> the old processor.

If forking the hardware is always easier than forking the software,
then either the CMS is braindead, or somebody thought it wasn't
necessary to apply it to hardware, too, which I count as "using it
very badly".

> If the old processor tries to use the SPI bus while it's
> disconnected let's hope the error handling in the old SW is up to
> snuff.

Given that the error symptoms this would cause to the disabled master
are stricly in the "this cannot ever, possibly happen" category, odds
are it's not.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

On 2005-07-08, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> Grant Edwards <grante@visi.com> wrote:
>> On 2005-07-08, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
>
>> Perhaps he's trying to avoid forking the firmware that runs in
>> the old processor.
>
> If forking the hardware is always easier than forking the
> software,

But nobody said that.

My reading of the OP was that forking the hardware is a given:
the new product has to have a new board.  Now the choice is
does the new product require forking the old firmware or not.

Assuming the old product must remain supported, it would be
nice if the old firmware worked in both products.

>> If the old processor tries to use the SPI bus while it's
>> disconnected let's hope the error handling in the old SW is up
>> to snuff.
>
> Given that the error symptoms this would cause to the disabled
> master are stricly in the "this cannot ever, possibly happen"
> category, odds are it's not.

I expect you're right.  

The chances of the firmware for the old processor being able to
tolerate being arbitrarily disconnected from the SPI bus at any
point are pretty close to zero.

At a minimum he'll have to connect the old/new processors
together with a couple pins so that they can negotiate over bus
ownership.

-- 
Grant Edwards                   grante             Yow!  You should all JUMP
                                  at               UP AND DOWN for TWO HOURS
                               visi.com            while I decide on a NEW
                                                   CAREER!!

Alexander Becher wrote:
> 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.

When you say access, do you mean Read and Write ?

It will be much easier if you can add support in the first uC -
SPI is not multi-master, so to simply OR-WIRE the bus, requires
handshake between the controllers. Your-turn/My-turn stuff, and
that should include write-time allowances.

One side effect of this sharing, is that it is still just possible a 
write/read will fail, so the firmware should include verify/retry.

If you had a system where the original was in ROM, then it is still
possible: One way is to create a virtual Flash device, that to the
original looks like the genuine article, but is actually your other uC,
and now it handles in SW the hand-over to the physical device.

This will restrict your second uC choice, as most small uC's have rather 
poor SPI Slave operation on multi-byte streams - or, you could use a 
CPLD to assist.

-jg