Pro Micro brownout issues,

I'm using a 5v pro micro, it's running a 24x2 character LCD and a 7 segment 6 digit LCD, and i am running the backlights for them via transistors, but using the 5 volt from the usb (the character lcd's backlight pulls about 15mA, and the 7 segment one pulls about 10mA.

That's all that is connected to the board, and i'm running a SafeStrings based sketch that reads the serial input and puts the text in the relevent places on the LCD's.

all was fine when i was using an arduino mega, uno or leonardo, but since switching to the pro micro, it's fine when i upload the sketch to the board, but if i unplug the usb cable and plug it back in it's not running.

well, something is running as i get a SafeStrings debug code in the main sketch :

"availableForWrite() returns 0
You need to specify the I/O baudRate
and add extra calls to nextByteOut() as only one byte is released each call."

This is kinda showing me it hasnt booted up properly, the LCD shows a line of blocks, and it does not respond to serial messages sent to it, just repeats the message above back on the serial monitor.

And i have tried it with the lcd's unplugged, same issue. if i short the reset pins, i get the 'de-de-dunk' sound from the computer as the board disconects it's self from usb, then the 'de-de-de-dink' sound as it re-connects and goes into bootloader mode, then 8 seconds later it disconects and reconnects, and it's back in normal mode, and it's running again.

On the sparkfun site they mentions an issue with brownouts...

"Code Runs After Upload But Fails to Start After Power Cycle
We found that an ATmega32U4 (like the Pro Micro 3.3V/8MHz) can brown out when outputting power to a boost converter. While code can run after uploading, a power cycle from the initial current draw to a boost converter is enough to cause the Pro Micro brown out. Thus causing the sketch to not run. This requires the user to toggle the reset button after a power cycle."

Now i'm not using any boost converter, but it does sound like it's this that's happening? but even when i have no lcd's connected so the only power draw is the board it's self and the 2 transistors,
tried it on my laptop which has 2 amp USB ports, a desktop with the old 500mA ports and a power bank... just to get the start up message showing on the lcd, and it's the same, only after a reset will it work.

I've tried soldering the J1 link, that cuts out the onboard power regulator, so i'm getting straight USB voltage to the board and hence the lcd's now, made no difference,

As the sketch dosent seem to be running when it's plugged in, a bit of code that toggles a pin to reset the board wont work??

Is there any code that can auto reset the board when first plugged it? or do i have to give up on using the pro micro for this project

well, something is running as i get a SafeStrings debug code in the main sketch

That’s a assumption on your part. If you research that error message, you’d discover that the library stops right there with a “while(1)” construct.

Don’t know why, don’t care to research it, zero interest in something based on String. That’s your end of the log. I’m just pointing out you’re ignoring the obvious.

Don’t know why, don’t care to research it, zero interest in something based on String.

It’s not based on String. It’s a wrapper around c-strings that provides String functionality (concat etc) in a (presumably) safe way ( although I did manage to crash a Nano with it :wink: )

yup, hence the name 'safestrings' apparently they should not crash due to heap memory corruption like Strings do,

and have lots of built in debugging which can be turned on and off... i have it on, hence seeing that message on the serial monitor when i re-connect the pro micro,

if i reset by shorting the rst pin to gnd, it'll boot up fine, but that'll get annoying having to do that every time the computer is shut down and re started the next day, when other arduino's seem to self reset.

It's not a brownout issue. You will have to open and close the serial port in the application that sends the data after disconnecting/connecting. This however also applies to a Mega or Nano.

To verify that your sketch is executing loop(), add a blink on the built-in led in loop(). The ProMicro does not have a built-in led on pin 13 but you can use the RX led on pin 17.

Regarding availableForWrite()

If a connection with the PC is broken (because you close the application), the ProMicro can no longer get rid of the data that is send over Serial; the buffer fills up and as a result you will eventually have 0 space in the Serial TX buffer.

This is specific to boards with native USB (like the ProMicro); a board like a Nano/Uno/Mega does not care if there is a connection; it just pumps the data out on it's TX pin (that is connected to the TTL-to-USB adaptor on the board).

You can slow down the ProMicro by closing the application that communicates over Serial with it. Although the safestring library might prevent that by checking availableForWrite (just assuming on the output that you provided). See below code to play with

const byte ledPinRX = 17;

void setup()
  Serial1.println("ProMicro debug");
  while (!Serial);

  Serial.println("ProMicro is ready");
  pinMode(ledPinRX, OUTPUT);
  Serial.print("ledPin = "); Serial.println(ledPinRX);

void loop()
  digitalWrite(ledPinRX, HIGH);
  digitalWrite(ledPinRX, LOW);

  Serial1.print("Serial.availableForWrite: ");

You will need two terminal programs; e.g. serial monitor and another terminal program (or a second instance of serial monitor). Serial monitor will be assumed in below to be 'connected to' Serial, the other terminal program to Serial1
Close serial monitor; open the application that communicates on Serial1.
Upload above code
Note that the only activity will be on Serial1 with one line "ProMicro debug"; the led will not flash.
Open the application that communicates over Serial (in this case serial monitor). You will see that the led starts flashing, that millis is printed and there is some debug info on Serial1
Close the application that communicates of Serial; observe the behaviour of the debug on Serial1 as well as the LED flashing; it will slow down.
Back to (4)

The line while (!Serial) prevents the code from continuing till a connection on Serial is established by opening the application that communicates on Serial; this prevents that the application e.g. misses the first data that is send from the Arduino.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.