SPI with multiple microcontrollers

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

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.

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

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

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.

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

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

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.

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.

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

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

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

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.

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

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.