SPI as comms but also for ISCP Programming - How...

Hello,

I am just working on a circuit and came across a situation I didnt fully know the answer to, so I thought I would post the question.

The situation is, I have between 2 and 5 microcontrollers talking to each other over SPI - all on a single PCB.
4 of the microcontrollers are AtTiny's, and one of them is a ATMega series.

Basically I am wanting to know how the SPI lines work when communicating to other devices, and when programming the device itself.

So I have comms bouncing around the SPI lines between the devices, and I want to reprogram one of the devices. If I connect my ISCP programmer to that device, then effectively all devices will see the programming data and bad stuff could happen. What is the normal method for going about this? How do you program while data is potentially flowing on the SPI lines to other devices?
Do I have to disconnect the device from the bus when I program?

Thanks
WanaGo

I believe that the reset line is held one way or the other during programming, if the reset line isn't connected between the chips only the chip plugged into the ICSP will get the reset signal and be programmable. The others may be confused by all the SPI data, but it shouldn't program them.

That's my understanding of things at least.

Give it a try... :\

Although, for safety I'd remove the SPI connection of the node you want to program, while programming it or turn the power off on the other nodes. Another thing is, for the SPI to communicate you need to pull down the SS line on the desired slave... which the programmer won't do if I remember correctly.

Give it a try, but I'm guessing you'll have to use the programmer in a standalone fashion.

The situation is, I have between 2 and 5 microcontrollers talking to each other over SPI

How are you selecting the message recipient? Typically, with SPI, the master uses a Slave Select line (SS) to control which slave receives a message.

Hello

Thanks for the replies.

Yes I have multiple SS lines going from the AtMega, one to each AtTiny.

My concern is, if I am programming one of the AtTiny's, the AtMega will be communicating to the other AtTinys at the time, so the SPI bus will have traffic on it.
I understand about the reset and the SS's, however there will still be traffic on the MOSI and MISO lines I would think, so that would interfere with the programming of the AtTiny.
Even if I put the AtMega into a mode so it stops talking, I am not sure if the traffic on the bus will be totally quiet? I would assume it is, but I dont know that for sure.

I am guessing I do have to somehow isolate the comms bus to the chip being programmed, just to ensure there is no crosstalk and other data coming into the chip being programmed etc.

This is all just on paper at the moment. These devices are going to be on 1 PCB, so I am just trying to determine the electronics side of it so I get the design right to start with.

Any more info, I am all ears.

Regards
WanaGo

I've already talked to Wanago about this offline but I'll post my thoughts here in the hope of generating more discussion.

I'm thinking that all resets should be tied together and SCKs jumpered to select the chip being programmed.

From the tiny84 (and all others I think) data sheet, the programmer will assert the reset signal then...

  1. Wait for at least 20 ms and enable serial programming by sending the Programming Enable serial instruction to pin MOSI.

  2. The serial programming instructions will not work if the communication is out of synchronization. When in sync. the second byte (0x53), will echo back when issuing the third byte of the Programming Enable instruction. Whether the echo is correct or not, all four bytes of the instruction must be transmitted. If the 0x53 did not echo back, give RESET a positive pulse and issue a new Programming Enable command.

This is what I remember seeing on the logic analyser. I suspect the chip being programmed doesn’t turn MISO into an output until it sees the 0x53 on MOSI. So if you jumper SCK only one chip will ever see the 0x53 and it will be the only one that turns its MISO into an output.

All others will remain in a reset state and blissfully unaware of what's going on.


Rob

I'm thinking that all resets should be tied together and SCKs jumpered to select the chip being programmed.

Excellent idea!

For the not-being-programmed processors, would a floating SCK line cause problems?

would a floating SCK line cause problems?

Possibly, a pull up/down resistor should fix that.


Rob

Thanks

So if the SCK is disconnected for 4 of the 5 devices, the reset is pulled low on all from the programmer, and the program is transmitted via MOSI and MISO to the chip being programmed... All the other devices still have MOSI and MISO connected, so I assume since their SCK isnt connected, they dont sync to the data coming in, so they ignore it?
I also assume they dont try and send anything during the programming saying 'I cant understand!' etc... which could cause problems?

As you can probably tell, im still quite new to SPI, I havent used it in anger before.

So the SCK's jumpered - do you mean that while a chip is being programmed, it is disconnected from the bus's SCK, or do you mean the other 4 devices are disconnected from the bus's SCK?
If the device being programmed is disconnected from SCK, then all the rest could still talk...
If the rest are being disconnected other than the device being programmed, then I assume this is what you mean?
And a common ICSP connector between the 5 devices? So disconnecting the SCK from 4 of the devices will leave the ICSP connectors SCK being connected to the device being programmed.

Sorry typing as I think... lol

As I see it, and totally untested of course...

Let's assume 5 processors in total.

All resets tied together.
All SCKs go to one side of a 2x5 header.
All SCKs pulled high with individual resistors.
Before programming pull all but one jumper.
When done put them back.

Could get a little tedious and there might be a better way (say with some logic, a 4-way analogue switch chip or something) but that's my first take on it.

All the other devices still have MOSI and MISO connected, so I assume since their SCK isnt connected, they dont sync to the data coming in, so they ignore it?
I also assume they dont try and send anything during the programming saying 'I cant understand!' etc... which could cause problems?

The others can't do anything, they are in a reset state. (assuming they ignore any MOSI data because they don't have SCK, a reasonable assumption I think but far from proven)

If the device being programmed is disconnected from SCK, then all the rest could still talk...

No, reset remember.

And a common ICSP connector between the 5 devices? So disconnecting the SCK from 4 of the devices will leave the ICSP connectors SCK being connected to the device being programmed.

Yep.

I'm reasonably certain it will work and so far nobody has thought otherwise, but I wouldn't get 50 boards made :slight_smile:


Rob

I'm reasonably certain it will work and so far nobody has thought otherwise, but I wouldn't get 50 boards made

haha

OK that sounds good.
So the reset signal during programming, is that held low for the whole programming sequence, or is it only pulsed for a period of time?
I was under the impression (for no reason at all really!) that the reset wasnt low for the whole programming. I dont know why I thought this though, so probably totally wrong.
Maybe thinking of RX/TX programming rather than ICSP, so not relevant.

I will continue to play :slight_smile:

Thanks

So the reset signal during programming, is that held low for the whole programming sequence

Yes. With one exception. If sending the Enter Program mode command fails, the programmer is supposed to pulse the reset line. This gets the programmer and target resynchronized.

I've done a little research.

From AVR910 app note (Smart | Connected | Secure | Microchip Technology)

When Reset is applied to the target AVR microcontroller, the MISO pin is set up to be an input
with no pull up. Only after the “Programming Enable” command has been correctly transmitted
to the target will the target AVR microcontroller set its MISO pin to become an output. During this
first time, the In-System programmer will apply its pull up to keep the MISO line stable until it is
driven by the target microcontroller.

So it's as I thought and it looks like we're on reasonably solid ground.

It's probably worth having a good read through this.


Rob