Go Down

Topic: Arduino Micro won't accept uploads anymore (Read 4861 times) previous topic - next topic

paulATchakobsaDOTnet

Apr 23, 2013, 01:50 am Last Edit: Apr 23, 2013, 01:54 am by paulATchakobsaDOTnet Reason: 1
Something has malfunctioned with my Arduino Micro. I had uploaded a sketch to it and now it won't accept uploads anymore. In addition, the Arduino IDE becomes extremely unresponsive whenever this Micro is connected. I have another Micro that works fine, it's something specific to this one (which was working before I uploaded list last sketch.)

One thing that may or may not be relevant is that the sketch I uploaded was example code that included the line Serial.being(115200). Prior to this I have always used the default of 9600.

When I reset the Micro I see Arduino Micro bootloader (COM6) appear in the device manager (this is on Windows 7) and then it refreshes to Arduino Micro (COM7).

While the bootloader COM6 appears the Arduino IDE responds normally and shows COM6 in the Serial Port menu. When the Micro appears as COM7 there are two different possible scenarios that occur and I don't know what causes one or the other, but I've seen both repeatedly. They are:

1) The Serial Port menu is empty even though Windows device manager shows Arduino Micro COM7. In this case the IDE works normally although I can't upload code.

2) The Serial Port menu shows COM7 but the IDE is extremely slow. Clicking on a word in the menu bar will open a blank menu that takes 30+ seconds before the words appear on the menu.

When I try to upload code despite the IDE being incredibly slow, I see that COM7 remains showing in the device manager. The IDE shows:

Code: [Select]
Binary sketch size: 5,012 bytes (of a 28,672 byte maximum)
Forcing reset using 1200bps open/close on port COM7


but the Micro apparently doesn't reset.

I've tried pressing the reset button strategically during the upload process but that hasn't helped.

The script I uploaded is below.

Code: [Select]
// BigNumber test: calculate e
#include "BigNumber.h"

void setup ()
{
 Serial.begin (115200);
 Serial.println ();
 delay(3000);
 Serial.println("Starting up");

 BigNumber::begin (50);  // max around 160 on the Uno

 // some big numbers
 BigNumber n = 1, e = 1, one = 1;

 int i = 1;
 BigNumber E;  // previous result
 char message[90];

 unsigned long start = millis ();
 do
 {
   Serial.print("Loop ");
   E = e;
   n *= i++;  // n is i factorial
   e += one / n;
   sprintf(message, "iteration: %d\te = %f", i, e);
   Serial.println(message);
   delay(100);
 }  while (e != E);
 unsigned long time = millis () - start;

 Serial.println (e);
 Serial.print (time);
 Serial.println (" mS");
} // end of setup

void loop () { }


Oh, one more thing. The message that most commonly appears when I try and "help" the upload process by pressing the reset button while the upload is just sitting there doing nothing is "Serial port 'COM7' is already in use. Try quitting any programs that may be using it." This message appears just about instantly when I press the reset button.

Also, I have verbose compilation and upload set in preferences so when I say the upload is sitting there doing nothing I mean that all the compilation messages have scrolled by and the message about Forcing reset using 1200bps open/close on port COM7 and then no other messages are appearing. Normally I would see the avrdude messages scrolling by, but not now with this problem.

Louis Davis

Try holding reset and continue to hole reset while you select Upload.
When the IDE says Uploading, release reset.

hiduino

#2
Apr 23, 2013, 05:02 am Last Edit: Apr 23, 2013, 05:38 am by hiduino Reason: 1
It looks like you are using a modified version of Nick Gammon's Calculate_E example from his BigNumber library.

Whenever you use Serial communications with a Micro it is recommended that you start your code with:
Code: [Select]

  Serial.begin (115200);
  // while the serial stream is not open, do nothing:
  while (!Serial) ;



That way the sketch will wait for you to open Serial Monitor before continuing with the rest of the sketch.

The part that is hanging up your sketch is the use of sprintf with floats.  If you comment that line out it seems to work with out hanging.  I believe that sprintf does not support floats.

You can try changing your sprintf to:
Code: [Select]

//    sprintf(message, "iteration: %d\t e = %f", i, e);
    Serial.print("iteration: ");
    Serial.print(i);
    Serial.print("   ");
    Serial.println(e);
//    Serial.println(message);


One more thing, if the Serial port doesn't show up in the IDE then you will probably need to close the IDE and reopen it again.

paulATchakobsaDOTnet

Through some lucky combination of reset button and unplugging-replugging the USB cable and quitting-restarting the IDE I was finally able to upload a different sketch and get the Micro to respond. Commenting out the sprintf in the original sketch and replacing it with a bunch of lines of print statements resulted in a working sketch.

I can't even begin to express how much I hate the absolutely primitive "print" command available on Arduino. Writing 4+ lines of code per line of output just to display the values of a couple of variables with labels indicating which is which is just nuts.

Thanks for the help. At least my Arduino Micro isn't ruined.

mlosuper

I would try the following code:
Code: [Select]

String message = "Iteration: " + String (i,DEC) + "     e = " + String(e,DEC);
Serial.println(message);

paulATchakobsaDOTnet

I've read in a number of places that the String variable type just shouldn't be used. I haven't bothered reading up on it, but the gist of posts I've seen in multiple places boiled down to "it's buggy, don't use it".

AWOL

I'm not aware that Strings are buggy of themselves, but you need to question if they're acceptable in a memory-constrained environment.

retrolefty


I've read in a number of places that the String variable type just shouldn't be used. I haven't bothered reading up on it, but the gist of posts I've seen in multiple places boiled down to "it's buggy, don't use it".


I don't recall all the details but the String library relied on dynamic sram memory allocation and release and there was a bug in that code. However the latest IDE release of 1.0.4 fixed that bug so that 'problem' should be history if you are using the current IDE release.

Lefty

Go Up