Go Down

Topic: Mega 644 problems (Read 7941 times) previous topic - next topic

wiz

Can anybody give me any clues about this problem?

I have repeated this with 3 chips mounted on a pcb and confirmed on a breadboard.
I have a mega644 with the ATmegaBOOT_644P.hex bootloader installed and the following code, used just because the problem is reproducible with this.

Code: [Select]

#define buttonPin 7
#define ledPin 31

void setup()
{
  pinMode(buttonPin, INPUT);
  digitalWrite(buttonPin, HIGH);
  pinMode(ledPin, OUTPUT);
}

void loop()
{
  digitalWrite(ledPin, HIGH);
 
  while(digitalRead(buttonPin) == LOW)
  {
    digitalWrite(ledPin, LOW);
  } 
}



There is a 10k pullup resistor on pin7 and a 100n cap to ground, the led on D31 is on when D31 is HIGH

After 20 - 30 rapid presses of the button on D7 the led extinguishes for about 7 seconds.

Forcing D7 HIGH during this period by applying 5V to it does not make the led turn on.

On any input pin except D7 everything works exactly as expected.

If I burn the hex file created by the Arduino ide to the chip directly by using avrdude with an avrisp programmer, bypassing the bootloader,  this problem does not happen.

I think the rapid button presses are rebooting the chip. 

wiz

I forgot to add, that if I leave the ftdi programming cable connected to the chip, then the program works ok, even if the other end of the cable is not plugged into the USB hub!? 

When D7 is pulled low there is a lot of activity on either the TXD0 or RXD0 pin, I can't remember which.

wiz

It has started doing it now with the hex file loaded directly. This is bizarre, three chips all exhibiting the same problem on different pcb's/breadboards. I am off to AVRStudio to see what happens.

jn777

Hi Wiz,

Why you did not used the ATmega644 bootloader instead of the ATmega644p one?

And in the code

  pinMode(buttonPin, INPUT);
  digitalWrite(buttonPin, HIGH);

Why write HIGH if buttonPin is set as an INPUT?

Regards

wiz

The chip is actually a mega644p so I tried all the bootoaders I could find for it.
I also tried with the internal pullups enabled and disabled, none of this made any difference.

I have tested with the same program written in plain C code, compiled directly by avr-gcc (on Linux) and the hex file comes out less than half the size of the one from the Arduino ide. For several hours testing this program performed perfectly.

For a control reference I just reloaded the bootloader and reprogrammed the chip by the ide and the problem returned immediately.

I think it's Gremlins hiding under the bench.

Coding Badly

Quote
the led on D31


Series resistor?

wiz

Quote
Series resistor?


Yes, the program works perfectly with any pin PB0-PB6 and PD2-PD7 as an input but not PB7.
This is with 3 different chips fitted to either of two pcb's or a breadboard and is repeatable in every case.

CrossRoads

@jn:
Code: [Select]

 pinMode(buttonPin, INPUT);
 digitalWrite(buttonPin, HIGH);

this turns on the internal pullup resistors

@wiz - I stuck in some comments:
Code: [Select]

void loop()
{
 digitalWrite(ledPin, HIGH);  // writes the LED PIN  high
 
 while(digitalRead(buttonPin) == LOW)  // if the buttonPin is Low the LED PIN is written
 {
   digitalWrite(ledPin, LOW);  // but the LED PIN is then immediately written HIGH after this,
 }                                            // so the LED will never be able to more than look  partly off when
}                                              // the button is pressed



I think you would have better performance doing it like this, only change state to high when the button is released, and not in between cycles of writing it off:
Code: [Select]

if (digitalRead(buttonPin == low){
digitalWrite(ledPin, LOW;}
else {digitalWrite(ledPin, HIGH;}
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

Coding Badly


What do you have connected to RESET / physical pin 9?

wiz

I just posted a reply and it hasn't shown up here? I'll try again.

The code above is just to give an example of how to reproduce the problem, not an example of how to write code, that is why it is a bit sparse & comment less.

The real code where I discovered this is several hundred lines long and is used to trigger inputs on a commercial sound player. It looks as though I am going to have to rewrite it in longhand C which I was hoping to avoid if possible.

The reset pin is pulled HIGH by a 10k resistor. I have had about 20 of these same pcb's scattered all over the world for 2 years and all are working perfectly, but none of them are configured to use PB7 as an input.

I have just had the board running again for about another hour loaded with the avr-gcc hex file and there have been no problems at all.

Coding Badly

Quote
I think the rapid button presses are rebooting the chip.

Quote
none of them are configured to use PB7 as an input

Quote
The reset pin is pulled HIGH by a 10k resistor


You suspect the processor is resetting, the input pin is physically close to the RESET pin, this is the first time you've used that pin as an input, and the pull-up resistor is relatively weak. 

I suggest: Tie RESET directly to +5V (or use a much lower value pull-up resistor) and run the test.

Try this...

Code: [Select]
#define buttonPin 7
#define ledPin 31

void setup()
{
  pinMode(buttonPin, INPUT);
  digitalWrite(buttonPin, HIGH);
  pinMode(ledPin, OUTPUT);

  if(digitalRead(buttonPin) == LOW)
  {
    while ( true )
    {
      digitalWrite( ledPin, ! digitalRead( ledPin ) );
      delay( 1000 );
    }
  }
}

void loop()
{
  digitalWrite(ledPin, HIGH);
 
  while(digitalRead(buttonPin) == LOW)
  {
    digitalWrite(ledPin, LOW);
  } 
}


wiz

Coding Badly. well done you are definitely going the right way, the chip *is* resetting,  but things are still not working.

I laid everything out on a breadboard (again!) to be sure there are no short circuits, and using your code with the reset pin tied to 5V the led turned on permanently and then responded to the button presses as expected for a bit longer, but still within a few presses the chip resets.

Normally at this point I would consign the chip to the bin but that would mean that I have either three chips, three crystals or six caps all with identical faults.

As a check again, I reloaded the avr-gcc hex to the same chip on the same board and it works indefinitely.

Something in the Arduino environment  (I don't like referring to the mega644 part as "Arduino" because it is not really an official part of it) is interfering with the reset functionality.

Coding Badly


Which core are you using?

wiz

I am using the Sanguino cores. I have just tried again with another brand new chip with exactly the same result.

And something else to make people think that I don't know what I am doing  :).

With the reset tied to 5V, I changed the pullup on the input pin to 1k which made no difference.

Removed the filter cap on the input pin and the program works exactly as it should.

Replaced the cap, ten presses of the button and the chip reset.

Reload the avr-gcc hex and everything works perfectly with the 10k pullup on the reset pin and the filter cap in place.

Coding Badly

Quote
Reload the avr-gcc hex and everything works perfectly with the 10k pullup on the reset pin and the filter cap in place.


With no bootloader, if the processor resets, your code starts running immediately (within just a few milliseconds).  How do you know that the processor is not resetting in this configuration?

Try this...

Code: [Select]

uint8_t reset_counter __attribute__ ((section (".noinit")));

#define buttonPin 7
#define ledPin 31

void setup()
{
  pinMode(buttonPin, INPUT);
  digitalWrite(buttonPin, HIGH);
  pinMode(ledPin, OUTPUT);

  ++reset_counter;
  if ( reset_counter > 1 )
  {
    while ( true )
    {
      digitalWrite( ledPin, ! digitalRead( ledPin ) );
      delay( 1000 );
    }
  }
}

void loop()
{
  digitalWrite(ledPin, HIGH);
 
  while(digitalRead(buttonPin) == LOW)
  {
    digitalWrite(ledPin, LOW);
  } 
}

Go Up