ISP and series resistor

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In one of the application, there are two micro controllers involved (Mega16 and Tiny44). They communicate with each other through SPI port. So far the devices used were DIP packages and as such they were programmed externally and then inserted in their sockets. Now we want to change the packages to SMD and hence the ISP method is opted for.

Reading the application note AVR910, it says that ISP programmer communicates over SCK, MISO and MOSI. To avoid driver contention, a series resistor should be placed on each of these lines if there is a possibility that external circuitry could be driving these lines.

This certainly is the case in my application. My question is what should be the value of these resistors.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1k should be fine.

OTOH, what have you put on the SPI lines?

A regular SPI device(s) is fine.
A high current relay or LED won't work with a 1k series resistor.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Reading the application note AVR910, it says that ISP programmer communicates over SCK, MISO and MOSI.

First, look in the datasheet for each device for "Serial Programming Pin Mapping" or similar.

It appears that the Tiny44 has USI and not "real" SPI? [I'm not a USI person.] Normally when programming an AVR with SPI devices attached, care is taken to keep the slave SPI devices de-selected during ISP operations. I don't know how you are going to do that with USI to keep the Tiny44 from interfering with Mega16 ISP.

It sounds like a tricky situation, as the ISP pins are "shared" so you can't just hold the "other" device in reset or it will try to react to the ISP commands.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks David. Both the controllers communicate with each other over SPI and these lines will be brought out to 6 pin header so that we can use AVR ISP mkII to program these IC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks theusch. I now realise the situation better. If during programming first device, the second is kept in reset and vice versa then I think it shall be all right. Also in this case there shall be no need for series resistors?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't see the problem. You just have two SPI devices on the SPI bus. The "ISP" function is only operational when that chip's /RESET pin goes low.

You obviously need the other AVR to be running and not using the SPI while the first AVR is being "ISP"ed.

i.e. in practical terms, you do not share the RESET pin on the bus. And you have a special run mode that ensures the SPI bus is free.

e.g. have a special hardware condition, such as holding an input pin low at startup.

David.

Edit. No, your last reply is wrong. The other AVR must be running when you are ISPing the first AVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David,
I did not mean to share the RESET pin (or tie them together). I just thought that SPI being inherently bidirectional, it is quite possible that while first device is 'ISP'ed the other device may want to give response. In such a condition, the data between programmer and controller being 'ISP'ed may get corrupt. I just thought if separately the other controller be kept in reset then it will not drive the lines.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Tiny44 just has USI. So it never goes haywire.
The mega16 has SPI. This goes haywire if you don't make SS an output.

All AVRs of all flavours start with all GPIO pins as input, and all peripherals disabled. So you just need to test an input pin at startup. Then you can run normally or 'run on the spot'.

You need 'run on the spot' to leave the AVR in its startup state or some other mechanism to ensure the running AVR does not access the SPI bus while the other is being ISPed.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The Tiny44 just has USI. So it never goes haywire.

Define "haywire".

ISP of the Mega16...

Scenario 1: Tiny held in reset. Tiny will attempt to respond to ISP commands sent to the Mega16. ISP sez "Erase Chip". Tiny sez "Cool!" and does it. Result: Haywire.

Scenario 2: Tiny not held in reset, and operational. Tiny watching the USI/SPI for commands. Gets a command that sez "Send Data" and responds. Result: the response corrupts the ISP sequence for the Mega16, and haywire.

IMO even though the USI does not have a chip-select per se, a soft chip select should be implemented. Then when the Mega16 is in reset for ISP there should be a weak external pulling resistor to keep the Tiny de-selected and ignore USI/SPI activity.

I'd recommend a chip-select mechanism in any case. Otherwise, how are you ever going to get back into sync after a glitch?

Considering the implications on the Mega16 side during ISP of the Tiny is left to the reader. I'd lean towards using the /SS pin as an input, driven high by the Tiny during normal operation, and weakly pulled low externally. Then the app in the Mega16 would monitor that pin and abort normal operation. Another in could be employed as well not directly tied to SPI operation.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am guessing that ISP is an infrequent operation and a human is available. I am also guessing that when running the mega16 is always a Master and the Tiny is always a Slave. Other SPI chips are also Slaves.

Let me also assume that PORTB.0 of either chip is an input.

PORTB.0 = 1;           //pull-up
while (PINB.0 == 0) ;  //run on the spot while pin is GND
...                    //continue with initialising regular app

To ISP one of the chips:
1. short PB0 jumper to GND of non-ISP chip
2. reset the non-ISP chip with momentary low pulse on /RESET pin
3. connect external programmer to the ISP chip
4. ISP program
5. rinse and repeat with the other AVR.
6. remove PB0 jumpers
7. both chips will run with their new firmware.

IMHO, an SPI bus should always have predictable signals on its DI and DO lines. e.g. a Master writes on the DO line and reads on the DI line. a Slave receives on the DO line and writes on the DI line.
Of course, if you like the SPI bus going haywire, you let the mega16 change roles when running. and get DO conflicts.

The mega16 does actually become a Slave during ISP.

All SPI devices will have real external pull-up resistors. This means they are in 3-state when not selected regardless of AVR.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

All SPI devices will have real external pull-up resistors.

Almost (IMO/IME). "All SPI slave devices in an app with an AVR8 master should have weak external pulling resistors on the chip select line to keep them de-selected when the master AVR8 is in reset (as during ISP)."

Some chip-selects are active-high; some are active-low.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finally I did get opportunity to try out what I had originally asked. The programmer that I used is AVRISP mkII. I used my current board to carry out the experiment. On this board the IC packages are DIP and they are mounted on IC sockets.

At my first step, I simply brought out the signals on six-pin header for respective IC. The SCK, MOSI and MISO were still respectively shorting to each other ( i.e. Mega16/SCK shorting to Tiny14/USCK; Mega16/MOSI shorting to Tiny14.MOSI and son on). I thought let me try the ISP method now. I made sure that while programming only one IC is present. The IC programmed perfectly.

With the connection same as above, I inserted both the IC in the sockets and tried out the programming (i.e. with MISO, MOSI and SCK still shorted respectively). There was corruption reported during the verification.

In my third step, I inserted 1K resistors between each of the three lines. The six pin header for Mega16 had all the signals coming from direct Mega16 Pins and same for Tiny IC. Keeping both the IC in the socket, I programmed turn-by-turn mega 16 and tiny IC from their respective header. They programmed (and verified) perfectly. The initial test shows that they run as per the expectations.

My question, do I need to do the 'run on the spot' method as David had said? Is there anything else I should look into as well? Sorry if my post is incomplete.