Strange problem in ATmega32A

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

Info:

I'm working on a project regarding home automation. in this project we put a circuitry inside of the regular switch board to operate the home appliances over internet. one of the feature of this project is "Lock Access" means user can specifically lock one or more hardware switches of that switchboard. In code I just use a 8bit variable to specify the current lock status of each 8 individual nodes(switches), and it also have backup stored in external EEPROM. To detect the current on/off status of hardware switches, i used 8 GPIOs with internal pull-up on and if switch is on it connects these GPIOs to ground.

 

Problem:

In normal condition (not inside the switchboard) the full hardware works without any problem with all function checked. But when i install hardware inside the switchboard then approximately 2/5 cases the nodes getting locked randomly and this happens only at boot-up if i unlock each nodes manually it works perfectly. but after another boot-up i faced same issue again. though if i disconnect the FRC cable of GPIOs (which connects hardware to physical switches), the lock problem disappears. also when i keep attached programmer this issue never happens.

 

Guideline:

1> The 8bit lock variable is initialized and successfully read from the EEPROM at boot-up every time this problem occur.

2> 8bit lock variable is not used anywhere in debounce and switches input code.

3> I2C bus @350k contains 24C512, DS3231 and ATmega32A with pullup of 4.7k.

4> hardware uses TRIACs to control appliances. though it includes zero crossing, interrupt and all stuff.

5> SMPS 5v 1A (1000uf at output) to power WiFi chip and ATmega32A at peak current of ~600/500 ma.

6> This hardware have another lock named "user lock" this lock have exact same code but issue didn't happen with this yet. (hardware have account system if user lock on then only Admin can access the node).

7> the code uses 3 external interrupts, 3 timers, Serial interrupt @ 9600 baudrate and on chip I2C interface.

8> the ground for hardware switches is not direct ground, it's through BC547.

 

Things i tried:

1> i checked hardware with more possible bypass capacitors (100n), additional delays to allow proper setup I2C devices (2 seconds).

2> me and my friend tried to find any bug in code but cant find one (though all works okay in normal condition).

 

Note:

I don't know this makes sense or not but once my friend soldered wires direct from hardware and switches which replaced old FRC cable. and this problem didn't showed up yet and its not sounds like proper solution, though i checked it on single hardware, and i'm not sure why re wiring effects this much. then i rechecked old FRC cable it passed continuity test and all. i have made these 10 hardware and this issue appeared in 4 unit (all shares same code same hardware same PCB structure and all component from same vendor) i tried faulty hardware at different location and problem remains same. the occurrence probability of this problem changes according to location, i mean at my home it occurs but rarely and at my friends home it happens like 50% of time.

 

 

 

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

I don't know this makes sense

Not to me, I gave up after the second line. So What is the strange problem?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

A picture might give us more to work with. Sounds like you have induction problems.

Last Edited: Wed. Mar 22, 2017 - 02:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@js When i test hardware in normal environment it works 100%, even though i tried picture tube degaussing coil straight near to AVR the problem didn't occur even after 30 attempts (during this attempts the buzzer was sounding like a bird). but when i install hardware in switchboard the issue remains same (nodes getting locked randomly at boot-up).

 

@Kartman induction issue possible, what should i do to be confirm it is induction issue? or any filter circuit to give a try?

 

Things i tried:

1> tried removing capacitor in SMPS which connects both ground (primary and secondary), problem remains same.

2> buzzer might include inductor so i put 10uf cap across to buzzer and even removed whole buzzer but no change.

 

Do TRIAC contribute to generate EMI in On/Off/Dimmer state?

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

How to determine induction? Look at it! Do mains wires run close to your low voltage ones?
Do triacs cause interference? Yes they do - that's why you have inductors for light dimming.
How is your circuitry earthed?
A decent picture allows me to evaluate a number of things.

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

the digital circuitry is isolated by opto-couplers so the distance is around 1 cm

the digital circuit is totally isolated from mains so no earthing. the Triac ans SMPS circuit only uses Ph and N

 

The GPIOs cable for switch status might be near to Ph and N because the hardware follows retrofit method so the whole switchboard will contain all wiring, switches and hardware in single box.

 

hardware pic is in attachment.

 

Attachment(s): 

Last Edited: Wed. Mar 22, 2017 - 07:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where's the emc protection on the inputs?

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

On the AC input of SMPS it contains EMC filter (diffrential choke and ceramic capacitor).

 

There is no other circuitry between switches and AVR. its direct GPIOs with internal pullups. i looked AVR040 application note on page 16 it shows some protection circuit built in but it says for ESD and application note is on EMC. its simply a forward diode to VCC so any high voltage spike on GPIO will be merged to VCC. (and external over voltage protection circuit will handle this ex. zener).

 

i don't know much about this point i might be wrong here.

Thanks 

Last Edited: Wed. Mar 22, 2017 - 08:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pratik Suthar wrote:

there is no other circuitry between switches and AVR...AVR040...for ESD and application note is on EMC....

 

AVR040 is nothing but an overview guide to the sorts of things to think about when designing with EMC in mind. It is not a complete guide to actual hardware design.

 

The diodes inside the chip are there primarily to protect the chip from ESD spikes not from EMC events.

 

 

Pratik Suthar wrote:

...any high voltage spike on GPIO will be merged to VCC. 

 

 

Will they? Have a look at this post and think again...https://www.avrfreaks.net/comment...

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "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." - Heater's ex-boss

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

I think you'll find most commercial designs will have some R and C for EMC. Also note you have the common mode capacitor across the transformer which means you can have around 1mA of leakage.

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

The mega32 has VCC and GND pins on each of it's four sides, yet I see no bypass caps on three sides of the chip.....

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
https://www.onegold.com/join/7134f67c2b814c5ca8144a458eccfd61

 

 

 

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

Thanks @Brain Fairchild i got your point. according to that post the high voltage spike will definitely harm microcontroller. considering the 0.7v of drop due to diode the DC input must be around 5.7 volts to get proper 5 volt and a zener diode after that dc input diode might help a bit. but yes that will be risky too.

 

@Kartman yes in many commercial devices the switches input was taken through low-pass filter and it helps to overcome denounce too. and i'm definitely going to try this out.

 

According to coding the GPIOs are only responsible to inform micro controller either switch is on or off and i used software debounce here which allows me to filter any frequency above 42Hz. the next thing i will do is RC filter. If any EMC noise coming from these data lines hardware filter will defiantly make benefit. Thanks again :)

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

ki0bk wrote:

The mega32 has VCC and GND pins on each of it's four sides, yet I see no bypass caps on three sides of the chip.....

 

Jim

 

 

Yes in PCB there is only one side bypass capacitor but during problem solving i put all possible bypass capacitors including these three sides, on reset pin, acros buzzer, RTC, and at VCC and GND out from FRC socket. but nothing got solved. Thanks

Last Edited: Wed. Mar 22, 2017 - 02:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Better go back and re-read the datasheet/app notes, bypass caps are required on all vcc - gnd pins!!!

 

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
https://www.onegold.com/join/7134f67c2b814c5ca8144a458eccfd61

 

 

 

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

Okay here it is, as ki0bk suggested added all four bypass caps permanent and added inductor on AVCC too. the main change which solved this problem was to change the code.

 

in past i was using single 8 bit variable to identify the lock status of each 8 switches (bit wise). and following was the code

 

if(lock_status & (1<<sw_number))

{

        //locked code here

}

else

{

        //unlocked code here

}

 

And in new code i replaced with an array of 8 with following

 

if(lock_status[sw_number] == LOCKED)

{

        //locked code here

}

else

{

        //unlocked code here

}

 

and this updated code is running fine with old hardware too, i still not getting the exact reason why this new way of writing same code solved this issue. I guess bad bit wise operation support in AVR, or an frequent interrupt occurrence though INT0 zero cross interrupt occurs at every 10ms and another timer1 interrupt at approx every 1ms along with other 4 randomly generated interrupts. IDK what it is, let me know what you guys thinking.

 

In addition what will be good inductor value for AVCC input? i currently use 100µH. I use 4 of 8 channel for ADC rest of 4 as GPIO.

 

And special thanks to js, Kartman, brian, ki0bk u guys are brilliant.

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

Pratik Suthar wrote:
I guess bad bit wise operation support in AVR

Highly unlikely!

 

Far more likely, a bug in your bit-wise operation implementation!

 

http://www.catb.org/~esr/faqs/sm...

 

 

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

Thank you awneil. yes you are right i can not consider its solved permanently. its still under test since last 10 days, lets see further if issue shows up or not.

 

This forums helped me a lot in problem solving. I really honestly thankful to all members here. awneil thank you for drawing my attention :)

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

The way to know that the it's properly solved is to be sure that you've understood the underlying cause of the problem.

 

Having identified that changing from individual bits to byte variables, that should help you focus on where the underlying cause lies (or lay).

 

Quite possibly, you had some code that forgot to mask-out the bits it shouldn't have been changing ...

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...