while(1) does not execute properly

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

hello everyone.

i am a beginner at avr. i have an atmega32. i wanted to make a password detector. when password is correct an led lights up. when it is incorrect another led blinks. the incorrect led is on pd6. but in place of blinking infinitely as programmed it just blinks once and stops. the program skips to the beginning of the main loop. heres the code.

#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
int main()
{
uint16_t time = 0;
uint8_t arcount = 0;
char password[6] = {'.','.','_','.','.'};
char entry[6];
DDRD |= (1 << PD7)|(1 << PD6);
DDRD &= ~(1 << PD3);
PORTD |= 1 << PD3; 
TCCR1B |= (1 << CS11) | (1 << CS10); //clock prescaler is on 64//
while(1)
{
while (arcount < 5 )
{
do
{
TCNT1 = 0;
}while(bit_is_set(PIND,3));
loop_until_bit_is_set(PIND,3);
time = TCNT1;
if (time > 11719)
{
entry[arcount] = '_';
}
else
{
entry[arcount] = '.';
}
arcount++;
}
if((password[0] == entry[0])&&(password[1] == entry[1])&&(password[2] == entry[2])&&(password[3] == entry[3])&&(password[4] == entry[4]))
{
PORTD |= (1 << PD7);
}
else
{
int back = 0;
while(back < 70)
{
 PORTD |= (1 << PD6);
 _delay_ms(200);
 PORTD &= ~(1 << PD6);
_delay_ms(200);
back++; 
}
}
_delay_ms(3000);
PORTD &= ~(1 << PD7);
PORTD &= ~(1 << PD6);
arcount = 0;
}
}

the while(1) in the if statement is the problem. the rest works fine.

also i made a test program that blinked an led as follows.

#include <avr/io.h>
#include <util/delay.h>
int main(void)
{DDRD |= (1 << 6)|(1 << 7);
while(1)
{
PORTD |= (1 << 6) | (1 << 7) ;
_delay_ms(1000);
PORTD = 0;
_delay_ms(1000);
}

when i did not write the ddr statement the led blinked fine though a bit dimly. but when i wrote that statement, the leds kept blinking randomly or sometimes froze in the on or off states.

please please help.

Last Edited: Fri. Jan 12, 2018 - 01:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i forgot to add that on pd3 there is a button attached to ground. when pressed for less than 3/4 seconds, it is recorded as a '.' and a long press as a '_'.

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

amihkan wrote:
when i did not write the ddr statement the led blinked fine though a bit dimly. but when i wrote that statement, the leds kept blinking randomly or sometimes froze in the on or off states.

Show a schematic or other diagram of your connections.  How many LEDs do you have?  How are they connected?  If only one LED, what is on the other pin (PD6 and PD7)?

 

-- LED blinks lightly because you are toggling the internal pullup.

-- When you make >>two<< pins outputs, I supspect there is attached circuitry on one of the pins that does not like to be driven hard high or hard low.

-- If your button is connected to ground, then you want to use the internal pullup.

-- Use the Code tags <> on the formatting toolbar to post formatted source code.

-- Buttons bounce.  You will need to use a proper sampling/debounce mechanism for your button, and a proper driver (state machine) for the output, not delay-driven.  If it were me I'd start with 10ms "ticks".

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

i had two leds only. one was on PIND6 and PIND7. thats all in the test program.

 

i did enable internal pullup. infact the led which lights up on the correct password(PD7) works perfect. but the other one just blinks once and then the program jumps to the lines after the else statement and subsequently to the beginning of the main loop.

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

What is the value of the current limiting resistor used for each LED? and what is the voltage of VCC?

 

Jim

 

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

uh -oh

ok i apologize i am a bit of a get things done kind of guy. so i never put current limiting resistors for leds.i know its kinda wrong but .......

 

as for vcc. i am not too sure as i am taking vcc and ground directly from my usbasp programmer.

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

amihkan wrote:
so i never put current limiting resistors for leds.
   Use 330 ohm resistors as VCC will be near 5v if using Vusb as source!

Until you add the resistors, we will not be able to help further.

 

Jim

 

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

Jim sir,

 

my cheap chinese multimeter puts it at 5.01v so roughly 5 volts.

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

Jim sir,

 

Thanks for the advise. I added the correct value resistors and they are working perfectly. but please explain me the reason behind this.

 

I am sorry for disturbing you and all others who helped me

 

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

How to properly connect an LED.

 

Either way works, the left methods lights LED when port pin is low, the other when port pin is high!

 

Jim

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

but why  do we need resistors.

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

but i promise that i wont even dream of an led without a resistor accompanying it.

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

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

amihkan wrote:
but please explain me the reason behind this.
Others have explained why the resistors are needed.

 

However, I believe the reason you were not seeing correct operation of the simple blink program was that trying to turn on both LEDs (without current limiting resistors) at the same time was putting to much load on the programmer power since you were/are

amihkan wrote:
taking vcc and ground directly from my usbasp programmer.

David (aka frog_jr)

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

so that can cause program malfunctions?

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

amihkan wrote:
so that can cause program malfunctions?
No, code execution malfunctions.

 

Edit:

Reading "program malfunctions" as programming, then there should be no problems as the LEDs will not be active.

Reading "program malfunctions" as program execution (after programming), then yes possibly...

 

David (aka frog_jr)

Last Edited: Fri. Jan 12, 2018 - 03:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

frog_jr wrote:
Reading "program malfunctions" as program execution (after programming), then yes possibly...

Define "instant".  Oh, wait, I meant "malfunction"...

 

Sometimes, someone will say that there is a malfunction when something doesn't operate as expected.  In that case, what is "malfunctioning"?  Is it the program?  Or the nut behind the wheel?

 

Consider these reported symptoms.  Now, let's say there is a weak power supply and OP's pins->diode->ground is drawing all the current the AVR will provide, and that then pulls the supply down into reset territory, whether power-on reset or brown-out reset.  Has the "program malfunctioned"? I'd say "no".  If one really cared to investigate the situation, then monitoring supplyV and examining reset cause will help to narrow down the situation.  Running with an ICE and recording the instruction sequence could help to document the "malfunction".  [but if it is indeed a supplyV drop, will the ICE be affected?]

 

I'm still curious about the connections.  Twice the OP said "led" -- singular.  No schematic yet given, but in answer to my query the response was "leds" plural.  Now, why would there be twin indicator LEDs on PD6 and PD7?  My guess still remains that there is some other circuitry on one of those pins.

 

 

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

theusch wrote:
Define "instant".  Oh, wait, I meant "malfunction"...

I saw what you did there

 

laugh

 

Sometimes, someone will say that there is a malfunction when something doesn't operate as expected.  

Indeed, a very common thread title here is, "XYZ not working as expected"

 

The first thing to check in such cases is always the expectation!

 

If your expectation is false or unrealistic - it ain't gonna happen!

 

 

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

theusch wrote:
Now, why would there be twin indicator LEDs on PD6 and PD7?
amihkan wrote:
when password is correct an led lights up. when it is incorrect another led blinks. the incorrect led is on pd6.

(emphasis added)

 

This would imply two LEDs one on PD6 (as stated) and another on "not stated" (PD7 looking at the first code listing).

The second code listing was for testing:

amihkan wrote:
i made a test program that blinked an led as follows

The code actually blinked both LEDs, which without series resistors may have overwhelmed the power supply.

David (aka frog_jr)

Last Edited: Fri. Jan 12, 2018 - 05:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

amihkan wrote:
so that can cause program malfunctions?

If nothing else, sinking too much current out of the supply will make the supply "brown out" (the voltage falls substantially), your AVR detects this in hardware and it resets. Repeat. Rinse. And... You have a blinking led.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

arcount needs to be volatile

 

volatile uint8_t arcount = 0;

 

 

277,232,917 -1 The largest known Mersenne Prime

Measure twice, cry, go back to the hardware store

Last Edited: Fri. Jan 12, 2018 - 06:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Torby wrote:
arcount needs to be volatile

???  Why would you say that?

 

First, I guess I concentrated on unexpected operation of the second/sanity check example.

 

Next, I don't see any ISRs or other indication that arcount could be modified by external means.

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

Oh. I THOUGHT I saw an ISR incriminating arcount. 

 

Was the code darklighted before? I'm finding it harder to read that it was.

 

277,232,917 -1 The largest known Mersenne Prime

Measure twice, cry, go back to the hardware store

Last Edited: Sat. Jan 13, 2018 - 04:15 PM