Random restarts of ATtiny2313A when buttons are used

Go To Last Post
63 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, dear colleagues! This is the first my post on avrfreaks forum.

 

I'm struggling with one frustrating problem - unpredictable restarts of my AVR chip. Here is the full story.

 

I'm designing temperature control system so I decided to use DS18B20 thermal sensor to control ambient temperature. Also I'm using HD44780 LCD and lcd_library by Peter Fleury to display some info. All electric connections (except high-voltage power supply module, see schematics) are made on bread board.

I wrote small library for DS18B20 1-Wire protocol and successfully employed it. All things were looking great - temperature readings is fine, CRC verification is OK and LCD worked perfectly, no restarts observed unless I attached three buttons to my ATtiny2313A.

 

I've made software debouncing of my buttons via non-blocking timer interrupts. For the first time I've programmed only one button (BTN_SET on schematics) while two other buttons just were on my breadboard and connected to the AVR chip. I must say that software part is working great - AVR properly reads signals from button and increases counter and displays actual info on my LCD screen. But sometimes reset occurs. I've tried to catch the cause of this unpredictable resets - I clicked the button very fast, very slow, hard ot soft - nothing matters. Sometimes reset occurred when I only touched but not pressed the button. In some moments of time reset event occurred when I touched my breadboard or nearby tripod when some of the high voltage lines hangs. Also reset (or another glitch) occurs when I power on hair dryer (about 2 kW) which is connected to the same power socket as my power supply, but when I select 1 kW mode no reset occurs. Also powering of 1.5 kW iron doesn't cause reset.

 

I decided to test my system by lefting it untouchable during the night time - for the first test no reset was observed while the second night test showed that some glitches are possible (lcd shows incorrect symbols or prints in incorrect positions).

 

So I completely stuck on these problem. I suppose that static discharge can cause these glitches but I may be wrong.

 

Schematics and full source code are attached here. All possible help is greatly appreciated!

Thank you!

Attachment(s): 

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

Last Edited: Tue. Feb 27, 2018 - 02:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Your schematic is hard to follow because of your reliance on net names rather then showing wire connections and normal convention with gnd on the bottom and power (vcc) on top!

I could not find on your schematic where the power is being controlled, or how it is controlled, can you explain and update the schematic to show that.

It would also help to see a picture of your setup.

 

Last but not least, I scares the HEQQ out of me when I hear beginners are attempting to control line powered devices, you do know it can kill! PLEASE USE CAUTION!

 

One thing I see that I don't understand is why you are using two voltage regulators, LM317 and a 7805? 

What is the output voltage of the 317 adjusted to?

 

Jim

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

I did not wade through the source code, but I did take a peek at the schematic.

 

--  Figure out how to trap and report MCUSR content when these "restarts" occur.  The mechanism will depend on your toolchain.

 

--  Does the app cycle supply power?  Is the BOD brown-out detector active?

 

-- I saw an "AC" on the schematic.  Do you get the same symptoms if e.g. running off a battery pack and no AC in sight?

 

-- (most of us would use the internal pullups on our active-low buttons to save components)

 

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.

Last Edited: Tue. Feb 27, 2018 - 03:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sometimes reset occurred when I only touched but not pressed the button

All good comments above.

 

That symptom definitely sounds like static electricity issue.

 

JC 

 

Edit:  Welcome to the Forum.

Last Edited: Tue. Feb 27, 2018 - 04:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The schematic is awful,...try at least making reasonable.   Regulator up at top, but power is at bottom.   Lm317 is backward...Vin should be on left.  Vout should go direct to LM7805.    Draw a complete power supply not some chopped up mess.   Vadj should be on bottom, goes toward gnd.    HOW does lm7805 gnd connect to rest of supply?  ywh is verethying noe ginta scrmalbe??

 

No filter cap on DS1bb20.  no output cap on Vcc regulator output (like 10uf), 0.1 is not enough.  Why is conn1  not by sck, mosi, miso?..a mess 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

dviktor wrote:
All electric connections (except high-voltage power supply module, see schematics) are made on bread board.
That may be the problem. Some breadboards may not securely hold wires/pins in place so that they might cause intermittent contact.

Check the wiring, wiggle the wires (gently).

Are the wires overly long or minimal length?

David

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


Edit:

There are some important differences between OP's schematic and mine.

OP has drawn an additional LM7805 between the output of the LM317 and Vcc.

This might be related to his problem.

What is the input voltage of the LM7805? It should be > 7V.

About the "problem" (I was too busy redrawing the schematic).

 

On some AVR's the Reset pin tends to be sensitive to EMI (touching suggests this is the case here).

On a well designed PCB (Short wires, GND planes) this is not so much of an issue, but with a breadboard and long wires it can become a source of unreliability quite easily.

An RC flter on the reset pin can help here.

With a Series R of 1k and a 100nF capacitor I calculate a corner frequency of 63kHz.

This could be a problem for ISP programming. You could bypass the filter, or remove the capacitor during programming.

An easy way to do this is to mak a plug which fits into the ISP connector with a Reset button and a Cap to GND.

A stronger pullup on the reset pin can also help. Think about 1K or even less.

1k = 5mA @ 5V, but only during reset, should not matter during normal operation.

 

PS. My math is rusty & crusty. Is this correct:

octave:3> k=1000

k =  1000

octave:6> n=1e-9

n =    1.0000e-09

octave:9> 1*k*100*n

ans =    1.0000e-04          // Calculated Time constant.

octave:10> 2*pi/ans

ans =    6.2832e+04        // Calculated corner frequency of RC circuit.

 

I've also redrawn the schematic to more conventional standards.

With "conventional" I mean that high voltages are at the top of the schematic, low voltages at the bottom.

Signal flow is from left to right and labels are only used where appropriate.

I've added a choke in the power supply, which should help in keeping out interferences from the mains power supply.

It also depends a lot on the transformer you use. "Better" transformers Especially torioldal ones tend to have a high bandwidth and can couple a lot of garbage ( From FL balasts or other things switching) into the circuit.

 

 

(Waauw, dragging an SVG into an edid window works).

 

 

I've also done something "behind the scenes".

I'm longing for KiCad5 with better library management. But untill then:

You should:

- Close KiCad and look into your Project directory.

- There is a file with the name [Project]-cache.lib.

- I usually rename that file by removing the "-cache" part. Then open KiCad and:

KiCad -> EeSchem -> Preferences -> Component Libraries -> Add -> Browse to your new lib -> Open

Your new lib is now added to the bottom of the "Component library files" window.

Single click it to select -> Up -> Up -> Up -> Up -> Repeat untill your lib is on the top of the list.

This makes your own components a permanent part of your your schematic and independend of external libraries.

Note that "AVR-ISP-10" is a custom component in this lib. with the labels slightly offset, so they do not cross the wires.

 Zip file of the project (With pdf, no SVG) attached.

Attachment(s): 

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Tue. Feb 27, 2018 - 05:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1


dviktor wrote:
Sometimes reset occurred when I only touched but not pressed the button. In some moments of time reset event occurred when I touched my breadboard or nearby tripod when some of the high voltage lines hangs.
This is normal for "breadboards" and loose wiring. It's called EMI (Electro Magnetic Interference). It is an unfortunate part of the harsh outside world, but also beneficial, because no wireless circuit (Radio's etc) would work without it. It's undesirable effects are usually combatted with Chokes, filters, short wires, GND planes on PCB's, Earthed metal boxes. Carefull filtering of any boundary between the circuit and the "outside" world.

Breadboards are also notiously unreliable. Great for testing simple things fast, but expect things such as these spurious resets to happen. Wiring the crystal oscillator on a breadboard is also an impossibility to do proper. The breadboard alone has a paraitic capacitance at about the same order of magnitude as the caps for your crystal.

For reliability you can cut off the Xtal pins just above your breadboard and wire your crystal in the air. Build something like:

The picture above does not have an Crystal at all, which is even better for breadboarding. Just expect some frequency deviation if you run from the internal RC oscillator (not so good for UART stuff).

 

dviktor wrote:
Also reset (or another glitch) occurs when I power on hair dryer (about 2 kW) which is connected to the same power socket as my power supply,
this is a well known problem, and gets worse when switching nearby inductive loads (FL ballasts, transformers) (your 1.5 kW Iron is almost purely resistive.

The Choke I did draw in my schematic #7 should help.

Any inductor based SMPS also helps. Those small LM2596 based circuits from Ali / Ebay are great for this.

 

And when breadboarding:

You've got long power rails. Feed in external power from the left side of those rails and power your uC from the right side of the rails and put a bunch of small decoupling caps along the rails, along with a buffer cap.

 

Have you ever wondered about those thick blobs on power cords?

Those are ferrite chokes and help in filtering EMI stuff. They work in 2 direction.

They  limit some of the noise generated by your circuit from radiating into the world (Any long wire is an antenna).

They also limit some of the noise from power lines from entering your sensitive electronics on your breadboard.

In my exprerience no uC power supply can work reliably without a choke or inductor of some kind. (Sometimes the power transformer itself is adequate, but not always !!!)

 

Note: EMI stuff is "high frequency" and has quite some "weirdness" to it.

Your own body is an antenna, and your hand near your breadboard is a capacitor which couples the high-freqency noise into your circuit.

This makes your circuit unreliable and is why Ground Planes are used on PCB's and pcbs are put into grounded metal boxes etc.

 

The Wikipedia article about EMI does not seem to be very good for beginners, nor comprehensive, but I'm not in a mood right now to look for a better reference as an introduction into EMI related problems.

https://en.wikipedia.org/wiki/Electromagnetic_interference

This might help:

https://duckduckgo.com/html?q=EMI+noob+introduction+combatting

Note that "EMI" falls into 2 separate parts. "Radiated" and "conducted", which must both be considered to make any electronic circuit work reliably.

 

To recap:

Your problem has 2 parts.

1). Sensitive reset line Caused by: Breadboard, long wires. Remedy by: Filtering, RC circuits, caps.

2). EMI -> Mains filtering, Chokes, Ferrite cores.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Tue. Feb 27, 2018 - 06:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you all for comments! I excuse for the bad quality of schematics - I'm only beginner! So I've updated schematics (in attachment) and attached some pics of my setup

 

One important notice: my transformer is connected to the 220VAC line (AC on the previous schematics) and then follows the rectifier. After it DC goes to the LM317 so I able to set any desirable voltage for any purposes (up to 13.5VDC). For some reasons I set LM317 output to the 8VDC (I have extra fan connected to my PSU and sometimes connect some other devices) so to obtain 5VDC for my AVR schematics I've installed another voltage regulator (LM7805) directly on my breadboard

 

@ki0bk:

I've updated the schematics. I'm using two regulators to keep two different output voltage levels from one PSU

Thank you for your precautions about powerful devices! But this is the case what motivated me to start learning embedded programming

 

@theusch:

1. Thank you for the MCUSR register advice. I'll test this as soon as possible

2. No, I haven't enabled any BOD fuses on my AVR. My fuses are: L = FF, H = DF, E = FF

3. AC is just the 220VAC line. I want to use the same line to power my fan heater (600W to 2kW, may be)

4. I've read somewhere that some glitches are possible when MCU misses some tics and internal pull-ups are not active when they should be and so accidental "button pushes" can occur

 

@DocJC:

All my suspicions are about static discharges too. Thank you for the greeting!

 

@avrcandies:

I've fixed the schematics. I've never heard about capacitor needed for DS18B20 device (what values for it you could suggest?). I've picked 0.1uF value for LM7805 output from their datasheet so I've decided that this value is reasonable

 

@frog_jr:

I've attached the photo of my breadboard so you could see the length of the wires. I try to keep them as short as possible

 

@Paulvdh:

The input voltage for the LM7805 is set to 8VDC (from LM317 regulator)

My reset pull-up is 10k (as on many other schematics). I'll try to use RC-filter, thank you for calculations and suggestion!

I want to say that these spurious resets started only when I've attached buttons and tried to use them. May be I just didn't seen them earlier

My transformer is ordinary (ТП114-7 for Russian values). You could see the datasheet here

Also thank you for the KiCad tips! I'm new to use ECADs for device engineering

Thank you for suggesting chokes for struggling for EMI. I'll give it a try. One thing that messes me: I want to manage fan heater (600W to 2kW) via external relay which will be connected via npn transistor to my AVR. Now I'm afraid that powering these external load will cause sensible current spikes. Could more inductive chokes help in that case? Or I should use another 220VAC line for powering such things?

I already have the buffer cap on the output of my LM7805. Is 0.1uF enough?

Thank you for the EMI-related problems explanation!

Attachment(s): 

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

Looks like your off to a great start with your project.

 

The DS18B20 NEEDS a 4.7 k ohm pull-up resistor on the DQ line to V+.

Also, put another by-pass cap, 0.1 uF, on the DS18B20's Vdd (V+) pin to Ground, very close to the DS18B20 sensor.

 

If you have another 100 uF cap, put it in parallel to C2.

If you have another 2200 uF cap, put it in parallel to C1.

Add an electrolytic cap to the output of the 7805.

Most of the capacitance should be on the output of the bridge rectifier, (C1), but you could use a bit more on the 7805 input, and you need a 10 or 20 or 100 or 220 uF cap on the output of the 7805.

The exact value isn't important.

 

Next, a small point.

You have two blue wires connecting your power bus to the upper rails of the upper breadboard.

Electrically this is fine.

BUT, try to start attaching colors to your power bus wiring.

Use a red jumper for your V+ rails, and black or green ("Ground" colors), for the Ground rails.

On a small project it won't make a lot of difference.

 

As your projects get more complex, it will make a difference.

Your eye will get use to seeing a red, V+, wire going to each chip and sensor's V+ connection.

Your eye will get use to seeing a black wire going to each chip and sensor's Ground connection.

Your eye will get use to seeing a by-pass cap, 0.1 uF across each of the power connections.

 

It will be easier to spot errors and debug your hardware if you develop this habit early.

 

Also, add a by-pass cap, 0.1 uF, across each of the breadboard power rails, or one where power comes into the breadboard, and another one along the middle of the breadboard.

 

Depending upon how much current you are drawing from the 7805 it might need a heat sink, also.

 

Next, get used to writing the input and output voltages on your transformer.

If you have a cheap DMM measure the DC voltage across C1.

Make sure C1 has a high enough voltage rating for the rectified DC voltage, or it will literally explode.

 

Next, know that power surges and spikes on the mains will get coupled through the transformer, and there will be voltage spikes on the secondary side of the transformer.

So, make the voltage rating of C1 higher than you expect to need.

 

Good luck with your project, it looks like it is coming along nicely.

 

JC

 

Edit: Typo

Last Edited: Wed. Feb 28, 2018 - 12:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The photo below shows another breadboard setup, although like I said, your setup is fine.

 

The photo shows some dental floss (string) used to tie some of the breadboard wires into bundles.

This makes it easier to see the hardware when making changes or debugging the project, and it adds a little bit of stability to the setup.

 

The very top of the photo shows red and green wires connecting the breadboard power rails.

It is easy to verify / know which wires and rails are V+ and which are Ground.

 

You might consider taping the bottom of your breadboards to aa piece of cardboard, (I use Plexiglas).

Then some masking tape along the sides has the power buses labeled, in this case you can see the +5, +3, and Gnd labels.

When you are tired, it is easy to make a connection to the wrong rail if you are not careful.

 

This project has a small electrolytic cap across a couple of the breadboard power rails also.

 

JC

 

 

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

Much better!!! As noted, you need caps added in various places.  Note, you can often get by with fewer caps, but why do it?  It's like holding up a heavy bookshelf with three screws & then deciding to remove two of them to save a few cents...later you really wish you had kept all 3 as you clean up the floor.  So put a bypass cap on each chip, regardless. 

 

What's this POWER_FLAG connected in two spots creating a short between power & gnd?

 

Also in your original schematic, was the 7805 gnd pin tied somehow to gnd?  Doesn't look like it to me. That could be the root of your problem, if that is how it is already built. 

 

R4 is correct, all the other resistors have a slight issue, in that one of the leads is non-existent.  You general should not connect at a right angle right on top of the part. 

 

 

The switches are drawn a bit backwards , the gnd connection should be below the pull up voltage..when you push the button , you pull down to gnd & the schematic should give a visual representation of that.  You will gain a lot of clarity drawing it with the correct perspective. Swap sw1 & sw3 locations and you will avoid some crossed pd4/5/6 wires, improving clarity further.

 

Pin 2  of conn 1 should show a connection to Vcc

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

dviktor wrote:
4. I've read somewhere that some glitches are possible when MCU misses some tics and internal pull-ups are not active when they should be and so accidental "button pushes" can occur

Better dig up that "somewhere".  a.  how does a micro "miss ticks"?  b.  how can internal pullups not be active, if you have properly activated them? 

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

@DocJC:

Of course, I have pull-up for the DS18B20, just forgot to include it on schematics

What if I just replace C1 with, i. e. 4700uF / 50V and C2 with 470uF / 50V instead of using four capacitors? Or is there any subtle pitfalls when using lesser amount of caps? I'll try to change LM7805 cap too

I already try to use consistent colors (and lengths) for wirings but wiring kit that I have consists of too little wires so I have to use another color

LM7805 consumes too little power (only AVR, 1 led and 1 LCD with dimmed backlight) so I can't feel any heat radiating from chip and I decided not to use heatsink on it

C1 is already 50V-rated cap so I think this is no problem with it

Thank you for the breadboard setup variant!

 

@avrcandies:

Ok, I'll try to use extra caps

PWR_FLAG is added because in other case the ERC checker shows that here are some errors on the scheme. Why are these flags should make short-circuit? I always think that one of these flags shows that GNDD is really "grounded" and the input of LM 317 chip is really voltage-driven. Or am I wrong?

Yes, in the v1 of schematics my LM7805 was solid-grounded

I've attached updated schematics

 

@theusch:

May be this was not good source of info (some of Russian forums) but because I'm the beginner I took that for granted. Thank you for advice. I'll try with internal pull-ups and post the results

 

Thank you all for the help. As soon as I'll have enough time to test with improvements I'll post here the results

Attachment(s): 

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

dviktor wrote:
Of course, I have pull-up for the DS18B20, just forgot to include it on schematics

No, there is no "of course" about it.

 

Many problems here are due to people omitting "obvious" components.

 

The whole point of the schematic is to describe what you have.

 

The schematic is the only thing we can see - so if it's wrong, someone will spot it!

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Nice work on the schematic, now it shows a temp sensor, some buttons, and a display device.  Not sure what the two color led does or how this device connects to the heater that is to be controlled? 

My guess is the two color led shows the state of the heater(On/Off).  How will you interface to the high voltage heater?  

In a similar project I used this isolated relay to control the heaters:  https://www.adafruit.com/product...

That way I did not have to mess with the high voltage side of the project.  Hopefully you can find some thing similar.

 

One more issue, the schematic shows an adjustable voltage regulator(LM317), but does not show what it is adjusted too?  Since it feeds an LM7805, it should be around 8 volts, but can not tell as its not stated on the schematic. 

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

You can certainly swap out the 2200 uF for a 4400 uF cap, might thought was you might have a bunch of 2200 uF caps sitting in your parts drawer.

For the low current drawn by your overall circuit, you might be fine with the 2200 uF cap as you have already have the circuit designed.

Rethinking this, you can leave that one alone.

 

I would still double up the 100 uF cap on the input to the 7805, (or use a 220 uF, or whatever).

 

Know that there is a big difference between putting two 100  uF or 2200 uF caps in parallel or using a larger one, and putting a 100 uF cap in parallel with a 0.1 or 0.3 uF cap.

One would think that the small cap isn't necessary, it adds very little capacitance to the circuit.

Actually, however, the very small caps and the very large caps have very different internal resistances and frequency responses, and the circuits need both.

 

I see you included a 10-pin header for programming the micro.

That is certainly fine.

The 10-Pin Header was, I think, the original recommended programming Header used by Atmel (?).

 

I think many designs use the 6-Pin programming header these days, it uses the same signals, but takes up less board space.

 

I think many of the newer AVR programmers have a programming cable with a 6-Pin connector.

 

So, be sure to take a look at your programmer so that you don't need to make a 10-Pin to 6-Pin adapter.

 

JC

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

PWR_FLAG is added because in other case the ERC checker shows that here are some errors on the scheme. Why are these flags should make short-circuit? I always think that one of these flags shows that GNDD is really "grounded" and the input of LM

You have the wire pwr_flag connected to the lm317 input and also have the same pwr_flg  wire connected to gnd...that is a short circuit! 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

@awneil:

This is just a mistake in schematics. I always use pull-up for DS18B20 however I've seen articles in which stated that these resistor is optional

 

@ki0bk:

Two-colored LED is just to control data integrity while talking with DS18B20. When CRC errors or another initialization fails occurs this LED is powered red and when all is good the powering is blue

As for now I have only power relay 507-1AH-F-C which is capable to handle 12A current on 250VAC line. But I need transistor circuit to drive relay coil and this is my next task. As for now I decided to make button interface to set up low/high limits of temperature control. In my source code I set foobar values for temperature limits and I print "Relay is on/off" on my LCD screen instead of driving real relay. But this is just the matter of time

My LM317 is set to 8V in this project. So I can connect simple fan to it and another LM7805 regulator to get 5V for breadboard schematics

 

@DocJC:

Thank you for explanation of capacitors. I'll see if I have any free caps or I'll buy some

My USBasp programmer (from aliexpress) have 10-pin header. However only 2 of 4 GND pins on it actually connected to the ground. Another 2 GND pins on programmer is connected to ATmega88a via resistors (not sure why)

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

I followed the KiCad manual and they set PWR_FLAG both to the VCC and GND. So I shouldn't connect PWR_FLAG to the GNDD?

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

In KiCad a lot of pins  of components in the schematic libraries are smart enough to know they must be connected to some kind of power source.

The PWR_FLAG is used in eeschem to tell eeschem that all the net's the PWR_FLAG's are connected to, are net's supplying power to your circuit.

 

Those symbols are used for design rule checking only.

Just like the "no connect" flag. Some hate it, but I like it very much that it warns you about pins which are flapping in the breeze when you try to make a PCB of your schematic.

 

From the Kicad Website:

http://kicad-pcb.org/

 

under "community" there are some links to fora (forums?):

https://forum.kicad.info/

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

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

So, I made a bit of upgrading and a bunch of tests. Here the results

 

@theusch:

I've tried to catch MCUSR register. I use avr-gcc toolchain and I added these lines to the beginning of my main function:

char reset = MCUSR;
MCUSR = 0;

Later in the code I just print out reset value. Right after ISP procedure I have reset = 0x6. If I power off my system and then power up it again I obtain 0x1 in the reset variable. But right after spurious restart I obtain 0x0! So I can't figure out what actually invokes that reset

After that I tried to use internal pull-ups - no luck. Resets occurred like in previous setup with external pull-ups

Right now I have no battery pack for testing but I have power supply from ZIP drive (5V 1A rated). I have been using it during my previous work and devices (DS18B20 thermometer with 7-segment LED display on home-made PCB) worked good for days and weeks. But using these PSU for my breadboard setup didn't bring any improvements. Moreover I got strange glitches with my setup - LCD was failing to start or strange symbols were drawn. So I switched back to my DIY PSU (as on schematics)

 

@avrcandies:

After actions given above I tried to put 10uF capacitor on LM7805 output. That seemed to be working - I could press my SET button for about 500 times and no reset was observed. After that I added 0.1uF cap to the DS18B20 power inputs and things were pretty good

 

@DocJC:

Then I have added 0.1uF caps to the power rails and LCD power pins. Also I've increased LM7805 capacitor to the 100uF and added extra LM7805 input capacitor rated at 220uF. From that moment I was able to catch some restarts (with MCUSR register equals to zero). Also my system become more sensitive to heavy load - earlier restarts occurred only at full-speed hair dryer but now even half-speed can restart my AVR

 

After all of these manipulations I moved my AVR logic part to the right of the breadboard and shortened some of the wires. Now I almost bypassed restarts on interacting with buttons (some restarts occur in random sequence despite of my actions, but more frequently along with static discharges in nearby things) but heavy load still causes AVR to restart (I even hear clicks and snaps in my PC speakers despite the computer is plugged in the UPS)

 

Some extra info. If I plug in my ISP header to the USBasp programmer but programmer itself is not inserted into USB port of PC then I can't get stable work of my system - AVR and all schematics keep restarts and sometimes I can see one measure from DS18B20 and MCUSR register contents which is 0x2. But if I plug USBasp into PC or unplug AVR-10 pin header completely then my system works pretty good. I think that this is related to the parallel connection of ISP lines and LCD data bus

 

Things I haven't tried: DC battery pack, inductive coil on AVR power input and ferrite choke on 220VAC power cord. But could current results give any useful info for deeper research? Thank you!

 

Also I've updated the schematics to the current state

EDIT: minor source update

Attachment(s): 

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

dviktor wrote:
I've tried to catch MCUSR register. I use avr-gcc toolchain and I added these lines to the beginning of my main function:
dviktor wrote:
But right after spurious restart I obtain 0x0! So I can't figure out what actually invokes that reset

As was speculated earlier:  It might not be a reset.  Your code is running amok for some reason.

 

EXCEPT:  [and I discount this because there was no mention of watchdog] Your toolchain may clear WDRF before it gets to main() to avoid cascading.

 

What can cause your code to run amok?  It could be a severe noise spike affecting operations.  It could be stack overflow.  It could be a null function pointer.  It could be (with your toolchain) an uncaught interrupt vector.  [the latter is worth exploring, with a BADISR...]

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

So I should copy the MCUSR value in the .init3 section to somewhere and check/clear MCUSR in my main routine? After that reset my global value which is in(dec)remented by buttons resets to zero so I begin with empty timer. Also my status LED undergoes power off-power on cycle (same is true for LCD screen - all its contents clears and then new strings are printed)

If it is stack overflow then I think it could happen on regular timings. Sometimes my device could live during the night without resets and sometimes it resets several times in 10 seconds when I try to press some buttons or move something with my screwdriver near the chip

The only interrupt I'm catching is the timer overflow interrupt. Could some other ISRs be fired if I didn't enabled any other interrupts?

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

If the sensitivity to your error conditions varies with moving things around on your breadboard that is a strong indictation the errors are due to EMI.

Your hair dryer esperiment also suggests this as did you earlier experiments by just "touching" a button (without pressing it ?).

 

If your uC is upset by EMI it starts doing random things and trying to find logic in there is completely futile.

When upset by EMI there is not much info you can get out of MCUCSR (or MCUSR).

Actually, not having any flag set in MCUSR vaguely suggest you uC is not reset.

EMI can corrupt memory, stack pointer, program counter, hardware registers or anything els on your uC.

 

As I said before BreadBoards are nice for quick experiments, but not for reliable circuits.

For that you need a proper designed PCB with a ground plane & supporting components.

 

As a stop gap method you can put a few of those splittable ferrite cores on your power supply lines.

Soldering the decoupling caps directly to your uC pins instead of putting them in the breadboard could also help a bit.

Or just stop using your hair dryer.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

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

I have not looked at your code, but have a general comment---are you debouncing or at least reading your switches multiple times?  If you instantly react to the first & slightest pulse on your switch inputs, then you system will be extremely hair-trigger sensitive to any noise spikes.   For example, rather than simply waiting for a switch input to "go  low" (pressed) before lighting an LED, you might read it at a rate of 50 times every 25ms.  If it is low ,say, more than 45 times in a row, declare it truly pressed & light the led.  Any violation of the rule resets the 45 count.  Once the switch is declared "pressed", a similar but opposite rule is applied to declare "released".  Single or small groups of spikes and glitches will be ignored.   Many creative debouncing methods are posted on the forum.

 

Sometimes simple upgrades like these can deflate the effects of nefarious EMI.  A cap on the reset line can help.

 

P.S. apparently your "pwr_flg"  is not some signal you you created (which would be a short in most packages, the way you drew it), but is some oddball KICad feature (probably why I don't use KiCad)

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

theusch wrote:
Your toolchain may clear WDRF before it gets to main() to avoid cascading.
It doesn't. (if you want that you have to provide it yourself). So sampling MCUSR at the entry to main() should be OK

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

dviktor wrote:
I always use pull-up for DS18B20 however I've seen articles in which stated that these resistor is optional

Then those articles are wrong - a pullup is definitely required (although it may be a "active" pullup)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Your toolchain may clear WDRF before it gets to main() to avoid cascading.

clawson wrote:
It doesn't. 

Haven't seen a bootloader mentioned, but a bootloader might also do that ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, the night is over and I could say that my system is stable for about 12 hours. Before to go to sleep I set some value on AVR and go away. Now I see this value and 0x1 MCUSR register - the same as from the beginning of the experiment (I manually re-powered AVR). Also I wrote code to another two buttons and seems that they working good

 

@Paulvdh:

Yes, it seems to be related with EMI. Ferrites is my next point (but should I put some pf them on my DC power lines? Or only choking the AC input by them is enough?). Soon I will have real PCB on the hands and will try in more realistic conditions

If EMI corrupts some things could this be related to the corrupting of string constants which is printed on my LCD? I do clrscr() every while cycle

PS: hair drier is just useful thing for experiments :) Also want to say that 600W fan heater doesn't cause resets

 

@avrcandies:

Yes, I have the debouncing (non-blocking). Every ~30ms I enter the timer ISR and check the state of the buttons:
 

volatile char BTN_SET_PUSHED = 0;
volatile char BTN_SET_ACTIVE = 0;
volatile char BTN_DOWN_PUSHED = 0;
volatile char BTN_DOWN_ACTIVE = 0;
volatile char BTN_UP_PUSHED = 0;
volatile char BTN_UP_ACTIVE = 0;

ISR(TIMER0_OVF_vect) {
    /* don't allow simultaneous button presses */
    uint8_t btns = ((BTN_PIN & (1 << BTN_SET)) << 2) | ((BTN_PIN & (1 << BTN_UP)) << 1) | ((BTN_PIN & (1 << BTN_DOWN)));

    if ((btns == 0) || !(btns & (btns - 1))) {
        BTN_SET_PUSHED = BTN_SET_ACTIVE = BTN_DOWN_PUSHED = BTN_DOWN_ACTIVE = BTN_UP_PUSHED = BTN_UP_ACTIVE = 0;
        return;
    }

    if ((BTN_PIN & (1 << BTN_SET)) == 0) {
        if (!BTN_SET_PUSHED)
            BTN_SET_PUSHED = 1;
    }
    else {
        if (BTN_SET_PUSHED) {
            BTN_SET_PUSHED = 0;
            BTN_SET_ACTIVE = 1;
        }
    }

    if ((BTN_PIN & (1 << BTN_DOWN)) == 0) {
        if (!BTN_DOWN_PUSHED)
            BTN_DOWN_PUSHED = 1;
    }
    else {
        if (BTN_DOWN_PUSHED) {
            BTN_DOWN_PUSHED = 0;
            BTN_DOWN_ACTIVE = 1;
        }
    }

    if ((BTN_PIN & (1 << BTN_UP)) == 0) {
        if (!BTN_UP_PUSHED)
            BTN_UP_PUSHED = 1;
    }
    else {
        if (BTN_UP_PUSHED) {
            BTN_UP_PUSHED = 0;
            BTN_UP_ACTIVE = 1;
        }
    }
}

Then in my main loop I check current state of buttons and do things properly:

ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
    if (BTN_SET_ACTIVE) {
        value = 0;
        BTN_SET_ACTIVE = 0;
    }

    if (BTN_DOWN_ACTIVE) {
        value--;
        BTN_DOWN_ACTIVE = 0;
    }

    if (BTN_UP_ACTIVE) {
        value++;
        BTN_UP_ACTIVE = 0;
    }
}

So i have no delays in ISR and my buttons are debounced and working on release event

 

@awneil:

Yes, I don't trust these articles and have always used pull-up for DS18B20

I'm not using any special bootloader - just a virgin chip from Aliexpress and simple hex program. So I think that this is not the cause of emptying MCUSR. Moreover I can see different MCUSR contents on different external resets - ISP, repowering and so on. But not in case of my glitch

Attachment(s): 

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

Are you requiring the buttons to be sampled many times before declaring them in one state or another (doesn't appear so)?  One sample is obviously no good, and 2 ,well maybe.   I like to have a counter for each button, each IRQ sample counts up for  pin "hi" & down if "low"  (with rollover/under prevention).  There are hi & low count thresholds to meet that set the defined button state.   The wide separation between the levels gives a strong immunity to random pulses.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

I just supposed that with my crystal resonator (8MHz) and current timer settings (prescaler is 1024, count to 255) the ISR will be invoked one time per 1 / (8000000 / 1024 / 256) = 1 / 30.5 second. So I think that steady-state processes should calm down during these 32 miliseconds. Now I extensively testing this scheme and results are pretty good - no double-clicks or glitches because of long-press is observed because I catch button release and act depending on that moment of time

 

Seems like restarts definitely related to the static charge issues - right now I have discharged to the nearby tripod on my desktop and "reset" event occurred. Could some zener diodes help here? Also i wonder will the situation become better if I hang some capacitors directly on buttons?

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

Zener diodes are not rated for ESD. Capacitors are a better choice as they act as a ‘brick wall’ to the fast ESD pulse.

As mentioned, your debounce is not good. A 10ms tick (100Hz) is probably a better value to work with. There are a number of techniques - up/down count as avrcandies mentions or i tend to use a simpler method whereby if the button input is not pressed, i load a variable with, say, 5. If the button is pressed, then i count down the variable by 1. If it gets to zero, the button is considered pressed.

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

If your circuit is upset by EMI anything can happen, as I said before.

(except maybe your uC turning suddenly in a peunea)

If your string is in ram (data buffer) it is able to be corrupted.

 

To combat EMI you have to locate the source first, or just "try to protect everything".

Your hair drier is an usefull tool for emi testing.

Switching anything with transformers nearby is also a good test as are fl lights with old fashioned ballasts ( Bunch of metal plates and copper wire).

Some apliances produce much more emi than others, so you should try a bunch of other apliances you have lying around.

Maybe you have a particular "bad" vacuurm cleaner.

It's not a very scientific method but wen you have first identified a few apliances which generate the most noise, and then a way to make your circuit immune to it you're quite far to something reliable.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Fri. Mar 2, 2018 - 11:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you all for your advises! I'll try to play around with button debouncing more. But I will need a slower crystal because I already use timer counter at max level

I think that I will be able to employ ferrite chokes soon. Also I've seen in AVR042 App Notes that coil which is in series with VCC pin of AVR could help but I wonder how to carefully select its nominals. Is the maximum current of it should be the multiple of my AVR load? How much is the L value of the coil should be? Or does there no strong limitations exist?

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

Why will you need a slower crystal? Use the timer in ctc mode rather than interrupt on overflow.
Ferrite beads are for rf emission. They won’t help your problem methinks. Toroids might help, but you need to find out where the transient is getting in.

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

Or, yes, you're right... Just need to sleep more - no good things will come to mind at 3 A.M.

I'll try remaining ways and post here if it will solve the problem

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

 i tend to use a simpler method whereby if the button input is not pressed, i load a variable with, say, 5. If the button is pressed, then i count down the variable by 1. If it gets to zero, the button is considered pressed.

I use counting in both directions so if, while the button is pressed, there is a loose connection or zap, the button won't suddenly be considered released (& then re-pressed).  It might not matter if the button is a "hold to operate", such as a  flashlight. However, if it is a selector (standby, align, launch), it might be more necessary.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

I was able to do new variant of button debouncing - by counter, as were recommended earlier. Now my buttons are more responsive and faster (I count to 5 and increment counter every 10 ms). After placing capacitors everywhere and moving chip to the right of breadboard things were fine until today. Now I store some of selectable settings in EEPROM (via eeprom.h routines such as eeprom_update_byte() and eeprom_read_byte()). I store only two values - lower and higher limit of temperature in addresses of 0x0 and 0x1 respectively and update them in EEPROM only on definite sequence of button clicks

 

Things were fine but this night a new "reset" occurred but this time not only the garbage on my LCD appeared but also reset of EEPROM 0x0 address happened - its value become 0xFF. I must to say that now I don't call lcd_clrscr() every time - I only redraw necessary part of screen so I think that the corruption of HD44780 RAM has occurred

 

There were no causes which could produce such a hard reset or electromagnetic spike. I think that something wrong may be with my ATtiny2313 - how can EEPROM corruption happen by itself?

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

Sounds like a glitch on the 5V rail.
Atmel has recommended not to use eeprom address 0 as it is likely to be corrupted.

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

Make sure your BOD fuse is set, though it won't solve all the world's problems, it can help if your supply glitches low before an EEPROM write can occur.  Did you add a serious capacitor to your 5V supply as requested?  0.1uf will not hold the processor power high during any sudden transients.

 

Things were fine but this night a new "reset" occurred

When, why --what was going on? 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

@Kartman:

Ok, will try to use another address

UPDATE: no, corruption is still occurs. I think that power spike (or whatever) causes the corruption of RAM and my menu status variables become invalid so my AVR thinks that user have entered new value for temperature limit and tries to save EEPROM. But because of unstable voltage EEPROM couldn't be properly written and corruptions occurs. The same is true for my LCD RAM

 

@avrcandies:

I enabled BOD level 4.5V as soon as started working with EEPROM. In my project writes to the EEPROM can only occur when I clicking SET button in edit mode. If I do not actions with setting my limits then no EEPROM writes should occur

I've fixed my powering earlier, see schematics here. I can't say what is the cause of tonight reset - no hair dryers, no heating fans or anything similar were switched nearby. Only may be the refrigerator or kettle in my hall (they are connected to the other power socket and placed as far as 5m along) but these devices didn't cause restart earlier

 

Because I am in testing phase now my breadboard setup is powered on almost in 24/7. After applying some upgrades (new capacitors, upgrading the values of the old ones, moving setup to the right side of the breadboard) as you all advised earlier the stability of the system increased significantly. I wasn't able to catch restart when clicking/pressing my buttons. In rare cases restart occurred when heavy static discharge nearby happened but this is the very rare events and this will not be the case in final device with good PCB, ground zones and other features. If I connect hair dryer in the same power socket as the PSU and power it on then sometimes some glitches happen such as the corruption of the strings on my LCD and other ones. To test my system any further I leave it alone while I'm sleeping or not at home. All these days after upgrade things were fine but these night something weird happened again - I don't know exactly what =\

 

Here I attached the last version of my source code - may be you find something suspicious in it

Attachment(s): 

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

Last Edited: Wed. Mar 7, 2018 - 10:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now I've attached my relay to the AVR (see schematics). Flyback diode 1N4001 is used in parallel with it. Transistor is KSP44 and it can handle collector current for about 300mA (relay coil consumes only 106mA). I use my transistor as switch so resistor for limiting base current is (Voh - Vbe) / (Ic / hFE) = (4.2 - 0.8) / (106 / 40 / 1000) = 1283 ohm and I choose 1k for it. Relay works perfectly (I use 75W light bulb for "Heater" resistor on schematics) but now I see more frequent "restarts" of AVR (but no EEPROM corruption observed). Relay is attached to the output of LM7805 regulator

 

Should I use second LM7805 exclusively for relay to prevent these glitches? Or any bigger caps could help? Also I've seen in AVR042 AppNotes that choke could be used in series with VCC. What are the criteria to choose it?

Thank you

Attachment(s): 

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

Your schematic is wrong.

 

An LCD, in 4-bit mode, uses D5-D7 not D0-D4.

#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: 2

Your problem is almost certainly down to using a breadboard. They are notorious for having poor connections and high resistance connections. You need to move anything 'power' off the breadboard and onto something more solid.

 

Also, you have too many random capacitors, they aren't going to help. Better to put the right value in the right place with solid connections.

 

An inductor in VCC will not help.

 

Do you have a scope?

 

What value DC do you measure across your 2200uF capacitor C2?

 

What value DC is across C3/C4/C5 (you only need one capacitor there).

 

C9, C10 and C11 are not needed on a solid layout.

 

You would be better to use a relay with a higher coil voltage and run it form your raw DC supply (across C2). It will draw less current and cause less heat in your regulators.

#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

Oops, what a silly mistake with data lines! fixed

I just waiting when my USB oscilloscope will be shipped (may be in two-three days)

On my C2 I have 20.0 volts (this is strange because transformer should give 16.5 during idle and 13.2 when on load). On C3-C5 group I have 7.69 volts

May be I remove C9-C11 when will test my circuit on PCB but now on breadboard it solves problem partially

 

Also I want to say that my relay is soldered to the wires and placed not on the breadboard. The only connection of the relay with the breadboard is done to the transistor collector and flyback diode

Attachment(s): 

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

Last Edited: Wed. Mar 7, 2018 - 12:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Your problem is almost certainly down to using a breadboard. They are notorious for having poor connections and high resistance connections. 

 

Also, you have too many random capacitors, they aren't going to help. Better to put the right value in the right place with solid connections.

I don't usually disagree, but I don't think bashing bread boards is the solution.

 

Have you seen Atomic Zombie's processor made from TTL chips?

It uses 20+ breadboards, (or whatever), wires everywhere, and it works fine.

 

I've been bread boarding projects for years, often with 4 or more breadboards, wires everywhere, and no problems.

 

Regarding the capacitors, I just told the OP to ADD more caps to his bread board, and to include all of the parts in the schematic!

 

Part of the reason for adding caps to his power supply is that he is using the "old school" approach with a transformer and a full wave bridge rectifier, not a regulated wall wart.

When the power supply has to power items like relays, with sudden large current surges, it is certainly appropriate to have lots of capacitance on the rectifier output, and throughout the power supply.

 

When using multiple bread boards is it also appropriate to have a couple by-pass caps on each power rail, (0.1 uF at the minimum, and perhaps also a 10 uF or higher), i.e. "Caps everywhere!".

 

Certainly a nice PCB would be desirable for the end product, but I suspect there are multiple issues at play here, and no reason a bread board set up can't be used to sort out many of them.

 

Just my 2 cents.

 

JC

 

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

For my desktop setup I can use ywrobot power mb v2 power supply but in final device I have to make standalone one. I think that it worth to make two PCB's - one with high-voltage stuff (like PSU and relay switch) and another with TTL schematics. The only connections will be +5V power wires and 1 wire from transistor to the relay

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

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

DocJC wrote:
I don't usually disagree, but I don't think bashing bread boards is the solution.

But those are fair observations of issues inherent in solderless breadboards.

 

The fact that they can be used successfully - with skill & care - doesn't contradict the fact that there are issues.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dviktor wrote:

I think that it worth to make two PCB's - one with high-voltage stuff (like PSU and relay switch) ...

 

You don't always have to make PCBs. There's nothing wrong with techniques like 'dead bug' for power stuff...

 

#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

This is my current powering setup (I've added LM217 regulator)

Linear regulators parameters
  Input cap(s) Output caps Input voltage
LM317 (main PSU unit) 2200uF / 50V 100uF / 50V 20V
LM217 (LCD backlight, relay coil) 220uF / 25V
0.33uF / 50V
10uF / 16V 10.00
LM7805 (ATtiny2313A, LCD module only) 470uF / 16V
0.33uF / 50V
100uF / 16V 10.00

 

Relay coil consumes 80-106mA. AVR is attached to one KSP44 transistor in switch mode (about 4mA), one DS18B20, one LED (about 5mA) and three buttons with 10k internal pull-ups

 

This is the measurements of various params in two modes: when relay is on (active) and when relay is off (idle)

Measurement results
  Idle Active
LCD Vcc
LCD backlight current
4.90
19.6 mA
4.63
16.5 mA
AVR Vcc 4.92 4.77
LM317 output voltage 9.98 9.97
LM217 output voltage 5.00 5.00
LM7805 output voltage 4.97 4.97

 

So you could see that voltage on input pins for AVR and LCD controller changes considerably (BOD fuse is enabled for 4.5V on ATtiny2313A). Also when relay powers up I could see that LCD brightness and symbol contrast decreases significantly. Also flickering of some symbols on LCD is seen

 

Looks like two LMs in parallel influences one another greatly. My wish is to divide TTL power and "heavy" load such as relay coil and LCD backlight

 

Considering voltage drop values it seems that breadboard actually eats a lot of power because of poor connections or bad quality (ordered from Aliexpress). But now I doubt can I get two LMs to work in parallel without influencing one another on real PCB? Or are there some fundamental pitfalls exist? May be play with input/output caps on LMs?

Viktor Drobot
A.N. Belozersky Research Institute Of Physico-Chemical Biology MSU

Last Edited: Wed. Mar 7, 2018 - 10:28 PM

Pages