Extend program space by getting rid of bootloader on NANO

Question

I just have a complex program that runs on a NANO. Now when I use my printlns for debugging I am running out of memory.

I read about using a programmer to get rid of the bootloader that uses 2K space on a NANO. I bought an USBTinyIsp and got it to work successfully... almost I can program the nano as I wanted, but I do not get any additional space.

When programming with debug printlns I run into the same message as before which states the same maximum space within (I guess it was 30700).

Why is this the case? I thought the bootloader gets overridden when using a programmer and so frees 2K of programmable space.

Please note: I am not asking how to optimize my program code! Thank you for taking notice ;)

Thank you very much.

• Juraj: the 'New bootloader' has only 0.5 kB, but arduino didn't change nano.menu.cpu.atmega328.upload.maximum_size
• Gil: When I get in space crunch I will do the code on a mega then when it is debugged shrink it to the nano. Not a perfect answer but a workable one.

Answer 1

It's enforcing this line from the arduino:avr boards.txt

nano.menu.cpu.atmega328.upload.maximum_size=30720

To be clear, the board is assumed to have a bootloader, even if you're not using it to get the code onto the board, that is upload via programmer.

You could edit that and change some fuses yourself. But you could also probably just use MCUdude MiniCore, choosing an option that does not use a bootloader, e.g. ATmega328P with No bootloader, which gives you maximum upload of 32768:

328.menu.bootloader.no_bootloader.upload.maximum_size=32768

Keep in mind that in either case you'll have needed to set the fuses for not having a bootloader. As weird as this sounds, choosing the No Bootloader option in MCUdude MiniCore for the ATmega328P, and then doing Burn Bootloader sets these fuses for you, despite the name not actually burning a bootloader in this case. If you were to edit the maximum upload size for the Nano board, you would need to manually set the fuses similarly to what Burn "Bootloader" does for the MiniCore ATMega328P with No-bootlader option.

• GeKu: Thank you very much! Just tried your first point which worked like a charm! Saved me a lot of time, I owe you a beer!
• GeKu: Additional information: As i had a reinstall of my System, I also had to reconfigure my boards.txt. I stumbled over this blog, which is explaining the fuses quite well: martyncurrey.com/arduino-atmega-328p-fuse-settings
• timemage: I would make a point of reading the datasheet rather than that. For one thing it says "I imagine RSTDISBL is implemented for security reasons to stop the chip being reprogrammed or the firmware being downloaded". No, not really, there other features for that. RSTDISBL exists mostly to allow that pin to function as normal GPIO. Anyway, read the datasheet for more accurate descriptions.