Board stopped accepting new programs, flash at 99%

I was troubleshooting a board that has been in use for a couple years. The code has vastly improved since the last time this board was flashed so i loaded new code. It took it and works better but there was a small tweak i wanted to make, and tried to reload the code again with the tweak, and now i constantly get

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding.

Then i noticed that my flash usage was at 99%. So the previous program that did load would have been around there as well, since i just changed one constant value.
Could this have caused the problem, if so, how do i get it to start accepting programs again?

I can cut some stuff out of the program, and it would bring it down to about 91%, but it didn’t accept that either.

board is a custom Leonardo board - i started from the Leonardo schematic and laid it out on my own board so i can more fully use all I/O pins and not need to stick to the height and footprint of mounting an off the shelf leonardo board, while adding my peripheral circuitry. I am using PlatformIO through VS Code to program it. It had the bootloader loaded through the Arduino IDE. It has worked perfectly to date with other boards.

Could you please let us know what board this is and what the code is?

From the error one might guess its a board with a native USB port that's stuck in DFU mode but it would help to know which board.

99% of course is very tight, but what was the dynamic memory usage?

(OK, noted its a Leonardo. Posts crossed).

sorry, i realized i should have included that info, and i did reply above with that.

I’m not sure i know what you mean by dynamic memory usage. RAM is 89%. 2282 of 2560

You can try quickly tapping the reset button twice. Don't know whether you included a LED on pin 13, but on a Leonardo this would fade in an out to show its in bootloader mode. You can then upload the blink sketch to test.

Usually when you compile you get two statistics:

Sketch uses 4616 bytes (16%) of program storage space. Maximum is 28672 bytes.
Global variables use 182 bytes (7%) of dynamic memory, leaving 2378 bytes for local variables. Maximum is 2560 bytes.

The second statistic that would be of particular interest as it shows how much runtime memory (RAM) out of the 2.5k available on a 32u4 the program needs to start running. This does not take into account any further variables created "on the fly" while the program is running.

With just 278 bytes left available, I would expect the program to run into trouble at so,me point. You either need an MCU with greater capacity, or the code will need to be cut down to a more manageable level, although it sounds like you have already tried to do this.

that will involve cracking the case open. Since it’s 4pm on a friday before a long weekend, that will likely happen Tuesday. Will try then. Thanks.

The alternative is if you have a way to program via the ICSP header? The you can flash a bootloader and clear and reset the board that way. Its usually a good idea to design in the reset (and boot on ESP32) buttons even of they are just a discrete pinhole somewhere.

I expect that the board can be recovered. The trickier part will be adjusting the code. Maybe test uploading/running the code on a spare Leonardo or Micro board first - if you have one available that is.

For now, enjoy your long weekend!

That should not be a problem, you can safely use 100% of the flash since it does not change at run-time, at least not with the standard bootloader used for the Leonardo.

What does the compiler show as maximum size for the flash? Since you are compiling using PlatformIO / VS Code that might not be allowing for the flash memory used by the bootloader.

+1.