Show Posts
Pages: [1]
1  Forum 2005-2010 (read only) / Troubleshooting / Re: Mega error while programming bootloader on: October 19, 2009, 06:16:47 am
I've done a little more research and verified the burned bootloader with the AVR Studio and AVR Dragon. It turns out that the bootloader does get burned correctly. My procedure was to first erase the entire Atmega1280 chip, then burn the bootloader with the USBtinyISP and Arduino-0017. This gave me (again) the error I reported in my previous post.
Afterwards, I verified the bootloader with AVR Studio and the AVR Dragon ISP. Here's the result:
Code:
OK
Reading FLASH input file.. OK
Setting device parameters.. OK!
Entering programming mode.. OK!
Reading FLASH ..      OK!
FLASH contents is equal to file.. OK
Leaving programming mode.. OK!

So it turns out the Arduino-0017 programming environment reports a verification error, but the bootloader is in fact burnt correctly. There could thus be either a bug in Arduino-0017 or a bug in the AVRtinyISP...
2  Forum 2005-2010 (read only) / Troubleshooting / Re: Mega error while programming bootloader on: October 19, 2009, 05:48:38 am
Hi there,

I'm having the same problem as Gary Nutbeam describes: when I try to burn the Arduino Mega bootloader with the USBtinyISP from Arduino 0017 I get the following error:
Code:
avrdude: verification error, first mismatch at byte 0x1f000
         0x0c != 0xff
avrdude: verification error; content mismatch

On the other hand, when I burn the "arduino-0017\hardware\bootloaders\atmegaATmegaBOOT_168_atmega1280.hex" file with AVR Studio and the AVR Dragon the bootloader gets burnt just fine.

And the strangest thing is that the firmware burnt with the USBtinyISP and Arduino-0017 seems to work just fine; I can compile and upload programs just fine.
3  Forum 2005-2010 (read only) / News / Re: Arduino 0012 available. on: October 16, 2008, 08:43:42 am
Well it seems that replacing the code with your two lines of code did the trick! The entire program now runs like a charm again! This makes me wonder though why the interrupts are disabled (and restored to their previous state) by the millis() function. In the wiring.c file I found the following reason: "disable interrupts while we read timer0_millis or we might get an inconsistent value (e.g. in the middle of the timer0_millis++)" but I'm not sure whether this will affect my code too. Thanks a lot anyway Mikal!

regards,
Dr. D.

P.S. I looked at the implementation of the delay() function, and now it seems to me that this statement in the Arduino reference isn't true anymore:

"Certain things do go on while the delay() function is controlling the Atmega chip however, because the delay function does not disable interrupts. Serial communication that appears at the RX pin is recorded, PWM (analogWrite) values and pin states are maintained, and interrupts will work as they should." (source: http://arduino.cc/en/Reference/Delay)

Since delay() calls millis(), and millis() disables and restores the interrupts, this means that during a delay() the interrupts are regularly switched off and on. I wonder if interrupts still keep "working as they should".
4  Forum 2005-2010 (read only) / News / Re: Arduino 0012 available. on: October 16, 2008, 04:48:11 am
Thanks for testing my code mikalhart! I've tried your modified code on my Diecimila and there are a few things I noted. If you push the button at a relatively low frequency, say, 1x per second, there is nothing wrong and the program seems to run just fine. But as you start pressing the button more frequently (say, 10x per second or more) the program stops running at a certain point. I tried this with a non-debounced switch, with an external pull-up resistor (and the internal pull-up resistor was also enabled by the two lines of code you added).
The problem is that the pulses the IR receiver sends to the Arduino are only about 300 microseconds in length, and the pulses are spaced about 400 microseconds. This means that the frequency on the interrupt pin is about 1.43kHz.
Maybe the Arduino (with the new millis() implementation) can't cope with such a high frequency of interrupts?

-UPDATE-
I've tried to disable the "pulseTimer = millis();" line, and with that disabled the ISR can easily cope with the pulses being sent at 1.43kHz. So my conclusion is that the problem lies within the millis() function, or the use of the millis() function from within the ISR at such a high frequency.

thanks for your effort, regards,
Dr. D.
5  Forum 2005-2010 (read only) / News / Re: Arduino 0012 available. on: October 15, 2008, 08:20:46 am
Thanks for your quick response!

Here's an extremely stripped down version of my sketch exhibiting the problem I'm describing:
Code:
// constant declarations / definitions:
#define IRINPIN 0   // infrared receiver is connected to this interrupt, value + 2 = actual pin number on the Arduino

// variables for IR signal detection and processing:
volatile unsigned long pulseTimer = 0;
volatile unsigned int pulseCounter = 0;

// function prototypes //
void interruptCounterIncrement(void);  // when called, this function increments pulseCounter and sets pulseTimer to the current value of millis()

// + + + SETUP CODE + + + //
void setup()
{  pinMode(13, OUTPUT);  // using LED on Arduino Diecimila board
   attachInterrupt(IRINPIN, interruptCounterIncrement, RISING);  // interrupt is attached to pin 3 (hardware interrupt 0) for counting pulses coming from the IR receiver.
}

// + + + MAIN LOOP + + + //
void loop()  // using the LED on the Arduino Diecimila board to indicate the main loop is still running (not crashed/hanging)
{   delay(100);
    digitalWrite(13, HIGH);
    delay(100);
    digitalWrite(13, LOW);
}

// + + + FUNCTION DEFINITIONS + + + //
void interruptCounterIncrement(void)
{  pulseTimer = millis();
   pulseCounter++;
}

By "crash" I mean that the main loop is stuck / not running anymore. You can upload this sketch on a Diecimila and reproduce the infrared receiver input on interrupt 0 (pin 2) with a switch that it normally pulled up, and connects pin 2 to ground when activated. To see what happens to pulseTimer and pulseCounter you could print them to the serial port in the main loop.

Thanks,
Dr. D.
6  Forum 2005-2010 (read only) / News / Re: Arduino 0012 available. on: October 15, 2008, 06:58:54 am
Hi everyone!

First post, so please don't flame me for my ignorance...
I've got a piece of code that worked just fine in Arduino 0011 (MacOS X), but it causes crashes when compiled with Arduino 0012.

Code:
// variable declarations
volatile unsigned long pulseTimer = 0;
volatile unsigned int pulseCounter = 0;

// in setup()
attachInterrupt(0, interruptCounterIncrement, RISING);

// the ISR:
void interruptCounterIncrement(void)
{  pulseTimer = millis();
   pulseCounter++;
}

I think it has something to do with the "improved millis()" but I'm not sure how to resolve this problem. For now I'm sticking to Arduino 0011 which allows this code to run flawlessly.
The code increments pulseCounter, an integer in which I store the number of pulses (interrupts) that have been received on pin 2 (interrupt 0). I use this code to accurately capture the number of pulses I receive on a TSOP2238 infrared receiver. Furthermore, pulseTimer keeps track of the last time a pulse was received.

Thanks for your time,
-Dr. D.
Pages: [1]