Sharing JTAG pins with outputs

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

I'm working on an ATMega6450 design where I'll be using all the IO pins.  Programming and debug are via JTAG, but I also need these pins for output.  They'll be driving coils that can't be on for more than 1 ms in a 20% duty cycle or they'll overheat.  Will this be an issue, or will JTAG holding the chip in reset during programming keep everything low?  Will I be OK during debug, as long as I don't break with any of the coils energized?  Anything else I should be thinking about?  Thanks.

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

1) You should never rely on any pin being in any state during reset, chances are they will float and so you need pull-up or pull-down resistors on any lines that must have a 'safe' state during reset. Anything else is just a bad design and asking for trouble.

 

2) You will need to have a look at a JTAG waveform to see if feeding any of them to your coils exceeds the limits for the coils. Can you not move the pins around and put the coils elsewhere?

 

3) If breaking during debug with coils energised is a problem then you need to drive your coils differently. Without seeing you circuit we can only guess but a simple solution might be to AC couple the drive to the coil drivers.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

If you use JTAG for programming then obviously JTAGEN has to remain active. But to use the pins for plain IO you will then have to turn it off. That involves the double write of the JTD bit in MCUCSR. So your code will need to do that. However don't just do it immediately on entering main() or the time between power on and JTAG being disabled could be very short making it quite tricky to "catch" it as you apply power. So put in a bit of a delay before you disable JTAG or, if you can spare it consider wasting one of the IO to test a button or something to decide whether to do the JTD thing or not. So when you want to start with programming you can just hold the button. A delay (a second or two) might be enough though.

 

As for connecting energizing coils to the 4 JTAG pins. Surely you can put some of the less important IO (like your LEDs or whatever?) on those 4 particular pins rather than having something as sensitive to "disruption" as coil energizers?

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

clawson wrote:

If you use JTAG for programming then obviously JTAGEN has to remain active. But to use the pins for plain IO you will then have to turn it off. That involves the double write of the JTD bit in MCUCSR. So your code will need to do that. 

Good point.  Thanks for reminding me.  How do I know how long is enough?

 

clawson wrote:

Surely you can put some of the less important IO (like your LEDs or whatever?) on those 4 particular pins?

Great idea.  Unfortunately, I only have two push buttons, three dip switches, and no LEDs.  The push buttons will work as they're NO, but the dip switches go right to ground when switched; can't count on myself to always open them when using JTAG.  I can probably free up some pins elsewhere now that I'm in a corner and can't be so profligate.

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

Brian Fairchild wrote:
he drive to the coil drivers.
Brian Fairchild wrote:

but a simple solution might be to AC couple the drive to the coil drivers.

Thanks for the tip but I'm unfamiliar with this approach.  Can you elaborate?

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

On second thought, I guess 1K resistors to ground on the dip switch would solve the grounding issue.

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

lautman wrote:
I only have two push buttons, three dip switches, and no LEDs.

OK, I'll bite:  Can you give an idea of the use of the other 80 I/O?  ;) I'll guess something "repetitive" like an array of sensors...

 

Sometimes, with like a DIP switch, we'll "burn" one I/O to use as the common when reading the DIP switch.  Otherwise, it floats and the state of the switches doesn't affect the other I/O.  But you only have a few channels of that so it may not help pin count.

 

 

 

 

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

The main consumers of IO are 4 x 7-segment flip-digit displays. 28 segments x 1 coil/segment x 2 signals/coil (set and reset) = 56 signals. These are routed through H bridges to handle the power (20V @ 350 mA for 1 msec. for each set/reset) and current reversal. I'd love to multiplex but can't think of a way to do it.

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

lautman wrote:
I'd love to multiplex but can't think of a way to do it.

Sometimes we multiplex switches/buttons with the "column drivers" for e.g. 7-seg LED displays.  May not apply to your flip-digit.

 

Also, character LCD data lines can be manipulated when not actually updating the display with E(nable).

 

 

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

Yeah, I've used multiplexing with LEDs many times. Just couldn't figure out how to do it when each column and row basically had two lines instead of one.

I might be able to use your enable idea, though, as each H bridge has an enable input. There are 14 of them though. Not at my computer at the moment, so I don't have access to the 6450 datasheet. Do you know what the fanout is? Is it even spec'd?

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

Actually, I don't need to control the enables on all the bridges, just a couple to free up 4 IOs, but there would be other benefits to being able to control all of them.

Last Edited: Mon. Sep 19, 2016 - 10:20 PM