"hiding" the ISP lines behind a buffer/switch?

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

I have an application where the uC programming lines are broken out to a diagnostics connector.  However, as those lines are shared by the SPi bus during normal operation, those lines are toggling away at (relatively) high frequency.  In order to minimise EMI, i would like to effectively disconnect the ISP lines when there is no programmer present (which is of course 99.99999% of the time).

 

So, can anyone see a reason not to put say a quad 3 state buffer (ie 74HCT125 or similar) between the ISP lines and the diagnostics connector?

 

If i connect the external "reset" line to the buffer enable pins, and pull that line up with a resistor to VCC, when there is no programmer present, the buffer will be in HiZ mode, but when a programmer pulls the external reset line down, it will enable the buffer, which will pull the internal reset line down, putting the uC into programming mode.

 

In programming mode, where the programmer is the SPI master, the following are inputs to the target uC: SCK, MOSI, RESET so would be wired with the buffer outputs to the uC

 

and MISO is an output from the target uC, so would be wired to the buffer input.

 

 

In this way, i think, the external lines to the diagnostic connector will sit low during normal operation?  (they might need some high value pull downs to make sure they sit at a known voltage when the buffer is not enabled etc)

 

 

 

 

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

Possibly.  Some programmers may have a problem with this arrangement.  You'll have to do some testing, and you'll have to make sure the buffer behaves in accordance with what the target expects.

 

Have a look at the 'Serial Downloading' section in an AVR datasheet.  The algorithm for starting an ISP session is described in detail.  In particular:

 

 

If the buffer tri-states with the positive pulse on /RESET in step 1, then the programmer will no longer have drive control of SCK.  I'd guess a pull-down on SCK as you suggest might help.  Otherwise, perhaps a diode+RC filter before the /nOE pins on the buffer to keep the buffer enabled during short positive pulses of /RESET.

 

Something like this:

                     VCC
                      |
                      |
                      \
                      /
                      \
                      /
                      \
                      |
                      |
/RESET ------|<|------+-------- /nEN
                      |
                      |
                     ---
                     ---
                      |
                      |
                     GND

 

Although this might not even be necessary.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Nov 18, 2017 - 07:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely, when you program a target uC with say an AVRISP, the target is already powered (ie it's vcc rail is already high) and the programmer just pulls the reset line (pulled either by the weak internal reset line pull up in the uC, and/or by an external pull up R to Vcc) low to start the programming?  ie, RESET and SCK would go low simultaneously, which will still occur with a buffer in the way as both lines will go low practically synchronously, when the buffer becomes enabled?

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

RESET and SCK would go low simultaneously

The point made in the datasheet is that not all programming environments are able to ensure that is so, and where they can't there is an alternate means of entering programming mode which involves momentarily pulsing /RESET high.  Since I can't predict what programming environment the OP will use, I thought it prudent to point that out.  But as I said:

... this might not even be necessary.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Not even sure why you want to "hide" the programming traces. EMI testing is NOT done for manufacturing stages of boards or products. Its for user environments. So, unless you have traces that are more than a few cm long, I would not worry. 

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

ka7ehk wrote:

Not even sure why you want to "hide" the programming traces.

 

+1.  Layout so you don't create long antennas.

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

max_torque_2008 wrote:
... a quad 3 state buffer (ie 74HCT125 or similar) ...
DragonLair has a 74HC244 (octal tri-state driver) with series termination resistors.

http://aplomb.nl/TechStuff/Dragon/Dragon.html (3/4 page for the schematic)

 

"Dare to be naïve." - Buckminster Fuller

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

ka7ehk wrote:

Not even sure why you want to "hide" the programming traces. EMI testing is NOT done for manufacturing stages of boards or products. Its for user environments. So, unless you have traces that are more than a few cm long, I would not worry. 

 

Jim

 

Normally, as you say, why bother. But this project is a bit different as it has to meet some rather fierce EMC targets (I can't actually tell you which ones due to customer confidentiality) and because the hardware design of the enclosures and connectors etc is a carry over (the project won't fly with a full redesign) i have something like 100 to 150mm long traces running to the diag connector, right past the other I/O traces (often parallel).  Whilst we "cap" the diag connector with a grounded cap, i can measure on the bench some coupling to the I/O lines, and that has me worried!  Now, we might be ok, but times scales and budgets for this project simply don't run to a large amount of up front testing or simulation. I will be running some pre-compliance ENC work in mid Dec, but i really need it to pass those tests!

 

So, with that in mind, if by the "simple" application of a cheap buffer IC i can effectively "turn off" those clock and data lines that that would be a very good thing to do!

 

Programming is generally with an AVRISP, there is a bootloader and serial I/O on the diag connector for setup and logging, but currently we don't program the firmware that way due to security concerns, so that is what any buffer system would need to work with.

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

I found some old through hole quad 3 state buffers lurking in a little used drawer (remember when we used "glue" logic all the time eh ;-)  so i knocked up a quick test circuit.

 

 i though if it works like this, with wires all over the place, it should work for a real application.

 

 

 

Seems to work fine with an AVRISP generating the programming pulsecode, using the incomming reset line to enable the buffer.  Forgot to look what the programming clock was set too, but i usually leave it at 2Mhz for most stuff so it was probably up at that value, so i didn't have to slow things down for it too work.

 

When the incomming reset line is released by the programmer,the buffer jumps into high impedance state, and the targets SPi can go back to being the master and the programming lines that break out from the buffer are effectively decoupled.  There is a small amount of cross talk coming out on the SCK line, around 25mVpkpk (compared to 5vpkpkp on the internal SCK line), but at the moment there are no pullups / pulldowns which would probably shut those currents to ground.  Even so, that voltage is not going to cause much of an issue