Protecting a microcontroller - diyAudio
Go Back   Home > Forums > Design & Build > Parts

Parts Where to get, and how to make the best bits. PCB's, caps, transformers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 9th December 2007, 12:06 AM   #1
diyAudio Member
 
Join Date: Sep 2005
Default Protecting a microcontroller

I intend to have a microcontroller in my LM3886 audio amp used for general housekeeping and a digital pot volume control. To program this PIC microcontroller, there are five pins needed: 5V power, ground, 13V programming voltage, data, and clock.

Many designs that use a microcontroller have the uC programming port inside the enclosure on the PC circuit board. I want to have mine connected to the enclosure, accessible from the back. The idea is that when I want to reprogram the microcontroller, I won't have to take the case apart - I can simply plug my PIC programmer into the programming port on the back.

Being that the port will now be "exposed" to the outside world, should I put in any extra protection circuitry at the programming port to protect the microcontroller from things like static electricity?
  Reply With Quote
Old 31st December 2007, 08:38 PM   #2
diyAudio Member
 
Join Date: May 2005
Location: Hungary
pic has protection against electrostatic discharge, but if you put an RJ11 on the back, there is very little chance to touch it anyway. The only thing I would be careful, do not use RB6, RB7 (which you have the cable on, to the back) for other control like SPI, or, even better send the pic to sleep when not needed and use RB0 interrupt for IR receiver and upper RB change interrupt for buttons, rotaries.

When I still debugged my firmware I have used a piece of flat cable to get out of the box with an RJ11 at the end, where I have connected the ICD2.

Regards,

JG
  Reply With Quote
Old 31st December 2007, 09:16 PM   #3
diyAudio Member
 
Join Date: Apr 2003
Location: Portland,Oregon
Blog Entries: 4
Send a message via AIM to DigitalJunkie
Maybe you could put a couple of diodes off to the voltage rails,to protect the inputs a bit.. That way they could only swing within about 0.7V of the rails. (be sure to tie the diodes on the Vpp/13V pin to the 13V supply/gnd,instead of to the +5V supply!)

Might be kinda overkill,but I suppose it can't hurt.
  Reply With Quote
Old 31st December 2007, 09:57 PM   #4
VivaVee is offline VivaVee  New Zealand
diyAudio Member
 
Join Date: Jun 2004
Location: Auckland, NZ
You should protect the microprocessor port pins unless you are trying to make a high volume low cost consumer electronics product where your job is on the line over a fraction of a cent in manufacturing costs. As this is a DIY project, you can afford to do it properly.

For ALL ports going to the outside world, put a 1k ohm 0.5W resistor in series (between the micro port and pin on yr external connector. Then place one diode (1N4148 will do nicely) from each micro port pin to supply rail (cathode to rail) and another from port to ground (cathode to port pin).

This is a classic protection scheme for such ports that clamps the port pins to within a diode drop of the rail or ground, limits the current and does not rely on the fragile body protection diodes.

It will cost you little and will mean that you are now very unlikely to have to rebuild after an ESD 'event'.

If the programming speed is low then you can afford to increase the value of the resistor for even better protection.
__________________
Alan
Hope is not a reliable design discipline
  Reply With Quote
Old 1st January 2008, 01:53 PM   #5
diyAudio Member
 
Join Date: May 2005
Location: Hungary
You do what you want, but put another diode parallel to the internal one (look at for example 16f870 datasheet page 33 figures) makes it just a very very little more safe. Like if you put 2+2 diodes each pin. It just makes it more complicated. In the other hand, I appreciate what VivaVee says, but I would not put series resistors at RB6, RB7 to the programming interface if I do not want programming/debug problems.
There are ports you should be careful. I rarely use RA4, and the oscillator in is not protected as far as I know. Put the suggested serial resistor at MCLR, it is important. The others not.
I did killed several 52 style MCU with unknown reason, I also killed PICes but never with ESD.

This is my current preamp control circuit, JP2 goes to the relay board slecting input, muting etc., the stepper driver turns a black alsps (what I want to change now). The transistors are needed unfortunately, because in this I use older signal relays, sinking more than what the port capable for without the LED. It works since 2002.

Regards,

JG
Attached Files
File Type: pdf schematic prints.pdf (51.9 KB, 27 views)
  Reply With Quote
Old 2nd January 2008, 06:07 AM   #6
VivaVee is offline VivaVee  New Zealand
diyAudio Member
 
Join Date: Jun 2004
Location: Auckland, NZ
As mentioned, do as you please. I merely offer my advice from the point of view of a few 100,000 units in the field and good knowledge of what kills microprocessors and how to protect them. I prefer to spend my time designing things rather than fixing them so I consider the scheme I mentioned as cheap insurance.

I checked the data sheet for the PIC mentioned. The I/O ports are specified at a load capacitance of 50pF and the device runs at 20MHz maximum. I would not be surprised if the suggested 1k resistors worked fine on the two In Circuit Debug pins (RB6/7) following the same kind of logic used to dismiss my suggestion! But seriously, the main point is that a series resistor is really really worthwhile. The value is only point that we should be debating.

In the case of the in-circuit debug it would depend on how fast the debug system ran. IF the debug program/hardware ran at the system maximum of 20MHz (very unlikely in my experience with other processors) AND the port had the maximum allowable load capacitance of 50pF then a series 1k resistor would have a time constant of 50 ns which is the same as the clock period. The schmidt trigger TTL inputs probably wouldn't cope with this. But this assumes worst case clock speed and load capacitance. If either of these were more reasonable then it would work fine.

Designing for worst case: I would ensure the clock/data pulse is above the TTL threshold within the first 10% of the clock period. That means approximately one time constant at 10% of the 50ns clock period which is 5 ns. Allowing for the worst case load capacitance (50pF) makes the resistor value 100 ohms. ( time constant = R x C).

Or just put the micro in a socket (shudder) so you can replace/upgrade it when/if it dies ...
__________________
Alan
Hope is not a reliable design discipline
  Reply With Quote
Old 2nd January 2008, 09:19 PM   #7
diyAudio Member
 
Join Date: May 2005
Location: Hungary
VivaVee, I accept all what you say, but the last sentence is incorrect. I have never changed a pic to ESD issue (rather because it got 12V or overloaded). I accept your opinion, I also believe it makes it a bit more safe, but do not say if somebody does not do what you say will need socket for changing pics. This is incorrect and against practice. We have different design philisophy which is fine, I believe both works.

Regards,

JG
  Reply With Quote
Old 2nd January 2008, 10:23 PM   #8
VivaVee is offline VivaVee  New Zealand
diyAudio Member
 
Join Date: Jun 2004
Location: Auckland, NZ
Apologies, I should not have put in the shudder comment. Perhaps an icon with a winking eye would have helped ''

I would solder the micro directly to the board but then I have access to good SMD rework tools and tend to use much faster micros that suffer signal integrity issues with DIP/PLCC packages - even assuming that these packages are available.

But the low clock speeds (in this application) would not make a socket an issue. You might find it valuable to have the ease of use and flexibility that putting the micro in a socket would give you. For whatever reason.
__________________
Alan
Hope is not a reliable design discipline
  Reply With Quote
Old 4th January 2008, 01:53 AM   #9
diyAudio Member
 
DJ Exprice's Avatar
 
Join Date: Mar 2006
Location: San Francisco, California
Send a message via AIM to DJ Exprice Send a message via MSN to DJ Exprice
Just make sure the socket has a cap on it when it's not in use. That should protect it from ESD and the like.

-vb
  Reply With Quote
Old 8th January 2008, 08:49 PM   #10
diyAudio Member
 
Join Date: Jan 2004
Location: Palmerston North
Send a message via ICQ to samborambo
I believe an even simpler solution would be to use a standard serial setup (MAX232 and DB-9 connector) with a bootloader for firmware self-flashing. In my experience, bootloader flashing is faster and pretty reliable compared to using a simple programmer. The only disadvantage is that without a proper ICD interface, debugging isn't as flexible. You'll have to manual put in breakpoints or debug messages through the serial port.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
protecting a VR tube jarthel Tubes / Valves 14 10th May 2007 01:21 AM
why is my amp protecting? mbugua Class D 2 19th January 2007 01:58 PM
protecting mosfets in UcD zilog Class D 10 12th November 2006 08:52 PM
Protecting treble driver from DC? AndrewT Multi-Way 5 25th February 2006 04:33 PM
protecting my speakers from my GC damitamit Chip Amps 13 16th June 2003 04:46 PM


New To Site? Need Help?

All times are GMT. The time now is 10:00 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2