Pro Mini w/urBoot needs manual reset for OLED

My ProMini-PB connected to an OLED, nothing else in the ckt. This will not start the OLED (or maybe not start the Wire) when power is applied. The led will still toggle but no OLED display.
Once i press the reset button, the wire and OLED work as expected.

I have a Pro Mini with a ATMega-328PB processor. I installed the urBoot using the minicore board driver.

Any thoughts?
Thanks
John

I've removed all code that was not necessary to show the issue (see below)

*/
#include <Wire.h>
#include "SSD1306Ascii.h"
#include "SSD1306AsciiWire.h"

#define I2C_ADDRESS 0x3C

// Define proper RST_PIN if required.
#define RST_PIN -1

SSD1306AsciiWire oled;
//------------------------------------------------------------------------------
void setup() {
  Wire.begin();
  Wire.setClock(400000L);
  
  pinMode(13, OUTPUT);

#if RST_PIN >= 0
  oled.begin(&Adafruit128x32, I2C_ADDRESS, RST_PIN);
#else // RST_PIN >= 0
  oled.begin(&Adafruit128x32, I2C_ADDRESS);
#endif // RST_PIN >= 0
    oled.setFont(ZevvPeep8x16);  // Screen = 4 (0,2,4,6) lines X 16 characters (0 to 15)
    oled.clear();
}
//------------------------------------------------------------------------------
uint16_t i = 0;
void loop() {
delay(1000);
           asm ("sbi %0, %1 \n": : "I" (_SFR_IO_ADDR(PINB)), "I" (PINB5)); // Toggle LED
           oled.SSD1306Ascii::setCursor(3*8,0);
           oled.print(i);
           ++i;
}

Have you tried connecting a pin to the OLED RST (assuming it has one)?

Have you tried adding a small delay at the beginning of setup()? The OLED might need longer to complete any power-on reset and initialization than the Pro Mini.

Are you using the Adafruit display?
How is the display powered?
Is your mini 3.3V or 5V?

Its a DIY-More display 128 x 32. Board and display are at 5V.

Board has no RST pin, only Vcc, GND, SCK, SDA

I also noticed if I remove the display when powered, replace the display, even a reset button on the pro mini doesn't start the display (just stays blank)

A similar board with a 328P (i.e. not the PB) and the "standard" boot loader works as expected.

My next step is to program the 328PB using ISP and no boot loader.

So at this point I don't know if it's the 328PB, or the bootloader or the hardware board.

I should state that I've used this/these displays for a number of projects with no issues up to now. Same display with an ESP8266 works fine.

Try putting a 0.1uf capacitor between the Promini RESET pin and ground.

That board does not have a capacitor on the RESEST pin like the Uno or other 328 boards

That did it! Thanks.

I hadn't yet connected the scope to reset. I measured the power rise time which was pretty sharp.

Now looking at the reset, it seems the on board reset cap goes to DTR and not GND. Its one of those things one doesn't really see when looking at the schematic.

Of course this schematic may not match the board I have. I'll have to trace out the Reset Ckt. Also curious why the 328p (i.e. not th328PB) board seems to work.

Have to compare datasheets but the Power on reset threshold between the P and PB may be different.

I'll have to check. In the meantime, I physically verified on these boards the Reset Capacitor goes to DTR not GND. Now looking at the "official" pro mini schematic it is wired the same way, and yet I've never had an issue before with other boards.

Thanks again.
John

That was my mistake it goes to DTR and other boards don't have a cap to ground.
However there can be a big difference in how urboot does a reset as compared to optiboot. Urboot has a lot of options for checking the reset reason and what to do for each. I'm not all that familiar with urboot but I think adding the cap will make it assume there was an external reset.

The minicore installation of urBoot only exposes a few options:

I prefer to ground the DTR pin when not using a programmer (FTDI serial) because if I put a cap from Reset to ground, in theory with a cap from Reset to ground a reset from the DTR line may only provide 1/2 the voltage at the Reset pin.

Curious that I've been playing with the Pro Mini for years and have never had a reset issue and I was blissfully ignorant of the capacitor ending at the DTR pin. I guess for some reason the urBoot and maybe the AT328PB are more finicky about the reset function.

Yes, so it't not the correct solution to the problem.
Why do't you uncheck the SOLVED box and see if others have additional information.

Do you need a Bootloader?
There is no USB connector for direct programming.
Also when any Arduino (UNO , NANO) is used to program another UNO or Nano the Bootloader is deleted.

Note: I am not the expert here just curious, recently got a few Pro Mini's that I will test with an OLED.

Found this very old forum post regarding Bootloader and Pro Mini.

https://forum.arduino.cc/t/pro-mini-and-bootloader-needed-or-not/438131

I have a feeling that urboot starts a lot faster than optiboot does.
Did you try putting delay(100) right at the beginning of setup()

This is true. However, we would typically connect an external USB to serial adapter module (or cable) to the board. Although you could use an ISP programmer instead of that to upload sketches, you are probably going to want a serial connection to the board at least for debugging during project development, so it is convenient to use the serial connection for uploads as well.

The Pro Mini has a dedicated "FTDI header" specifically intended for the connection of an external USB to serial adapter. You can get adapters that have a header with the standardized pinout that allows you to plug it right into the header on the Pro Mini:

📷

USB-C_and_Arduino_Pro_Mini.jpg by Sparkfun - CC BY-SA 4.0 (cropped, border added)

I discovered that. I guess I was naively under the impression that the commands executed in sequence.

Thanks for the reply.

The Pro Mini is programmed via the bootloader from the serial port. I use an FTDI interface board to program this way. This of course requires a bootloader.

I could program this board using the ISP method of programming which will not require a bootloader. Without a bootloader the initial startup may be faster (milliseconds) but cannot be programed via the serial port. If I were to make a production device I would program the processor via ISP.

They are!

Was not really serious however I have to think, if a delay matters between "setup()" and "wire()" something else is going on.