What changes the pins to input after the bootloader?

I modified optiboot to set all the pins to low when booting but after the bootloader runs, something turns all of them to input, making them into a "floating pin". How can i eliminate this problem?

A little more info:
I have a custom board with mosfets on the output and i cannot use pulldown resistors for reasons i don't want to go into here. I need a solution that would pull every unused pins to low while the program runs. In addition, i do not want to modify the programs to not break compatibility with previous versions of the boards.

Is there any way to leave all pins low after the bootloader unless specified?

Hardware Reset sets all of the pins to INPUT.

Put a mild (10k?) pull-down on each pin you want to read as LOW on power-up. In your sketch, use digitalWrite(pin, LOW); before you use pinMode(pin, OUTPUT); to make sure they stay low when you turn on the output drivers.

As i said in my post, i cannot use a pulldown resistor, not even several hundred kiloohms, and i cant turn them off in the sketch either because that would break compatibility with previous boards.

How was this problem solved in the previous version? Did the pins go into low state when resetting?
If not, then by adding the changing of all pins to the LOW, you will just brake compatibility with the previous version of the board, since the new one will behave differently

The problem was solved with switched resistors in previous versions. If i modify the sketch, there is a chance for it to work against the state of the mosfets with the older versions. With the new version, i would like to eliminate the resistors and do the task with software. There would be a predetermined state for every board and that would not change with any sketch because they would all have their own bootloader.

The whole thing is too complicated so i would rather not explain this all so thats why i am looking for an answer for this exact question.

I don't understand "after the bootloader runs". After a Reset all pins are input and will stay inputs until some code makes them outputs.

Then stay away from any DIY electronics. There is no reason why you can connect MOSFET gates to GPIO pins but not to pullup or pulldown resistors. Did you forget to connect the MOSFET sources to GND?

You should disclose your reasons before the magic smoke appears.

1 Like

I don't understand "after the bootloader runs". After a Reset all pins are input and will stay inputs until some code makes them outputs.

As i said, it is a custom bootloader. The bootloader first sets all pins to output and sets them to low. It then does some other stuff and when the whole thing is over it flashes the onboard LED to let you know it has finished the boot sequence. Only after this does it jump to the start of the program and executes the sketch. And some point after it jumped to the start of the sketch, and something sets all pins to input. That is what i don't understand why and when it does it.

There is no reason why you can connect MOSFET gates to GPIO pins but not to pullup or pulldown resistors.

The mosfets used have a 5 megaohm input resistance. The biggest resistor that could pull it high or low is around 700 kiloohm which is substantially smaller than the 5 megaohm and can mess up certain measurements as i found out. So no, i cannot use external resistors. With a software solution, if i use the pin, i could switch it to a state i wish it to be in and if not, then the default low (or high, as prefered) can take care of it. The whole point would be to have a convenient way to deal with it and to reduce the number of components. I don't know why it is so hard to understand that i want a solution like the one described in the first post.

You should disclose your reasons before the magic smoke appears.

I know what i am doing. I am most certain the magic smoke won't come out.

That's one reason why your circuit should be fixed first.

We are used to cure XY problems.

My crystal ball suggests: Then you also have to modify the Arduino core code that runs before main(). And don't wonder if some other core functions won't work as expected after such a patch.

But i don't even know where should i look. I don't know what turns the pins to input. That is why i ask for help. "Somewhere in the arduino core" is not helpful.

@21levi970
Abuse and rudeness are not allowed in this forum. I have stopped you from posting for 2 days. If you continue to post abuse you will be permanently suspended from the forum.

Thank you

I do not see anything in the standard AVR core that does any initialization of the pin direction. The path goes like:

  1. C runtime init (initializes stack pointer, copies .data into RAM, zeros .bss)
  2. main() (main.c) calls init() and initVariant() and then setup()
  3. init() (wiring.c) initializes timers and ADCm but doesn't touch the GPIO
  4. initVariant() is empty on "standard" AVRs.
    setup() is the start of user code.

For optiboot-like bootloaders, the bootloader does not just "jump to the application", but instead triggers a WDT reset, which will return all pins to inputs for the duration of the reset state (until something reconfigures them. Normally optiboot would go directly to the sketch without touching pin configuration again. (also, on power-on, optiboot won't run, going directly to the user sketch.)
But it's not clear whether your "modified bootloader" is based on optiboot, or how it actually starts the application, or exactly when it sets the ports to output lows.

The mosfets used have a 5 megaohm input resistance. The biggest resistor that could pull it high or low is around 700 kiloohm which is substantially smaller than the 5 megaohm and can mess up certain measurements as i found out. So no, i cannot use external resistors.

This doesn't make sense to me. What MOSFETs (part #)? What "measurements"? You will need to go into a lot more detail about what you're doing for "us" to believe that pull-downs are not a solution.

1 Like

Maybe nitpicking (?) and you know a lot more about optiboot than I do. But I thought that

  1. optiboot always runs on any type of reset.
  2. It checks the cause of the reset; if it's POR, it hands over to the sketch; I don't know about the mechanism (possibly just a jump)

One thing has not been mentioned yet: remove the bootloader.
When the sketch is burned into the ATmega with a programmer, then sketch runs without the delay by the bootloader.

@21levi970 Everyone has problems with your question, and I have even more problems with your question ! The bootloader should not change the pins. The ATmega chip itself sets them to inputs during power-up. A mosfet needs a pulldown resistor to be off during a reset, everyone knows that, there is no way around it. When adding a pulldown resistor influences your measurements, then something else is going on, that means we need to see a schematic and we need to know more about your project. It is certainly a XY-problem in my opinion. I can guarantee you that a 10k pulldown resistor at a output pin has no influence on the output signal.

Please read this: https://xyproblem.info/

The actual problem is how the circuit influences your measurements.
The most simple cause would be missing decoupling capacitors. The most complex cause would be ground currents.

1 Like

Ok. technically, optiboot always runs. The first thing it does it check whether it was started by something other than an "external reset", in which case it immediately jumps to the sketch, within about 10 instructions total, none of which involve changing the GPIO configuration.

What I usually mean when I say the "the bootloader runs" is that it reaches the point where it blinks the pin13 LED configures the UART, and looks for upload commands.

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