Go Down

Topic: Sketch too big on Micro ?! (Read 239 times) previous topic - next topic


good day everyone, I  have a problem with a sketch which is using up almost the full flash memory size (30434 bytes). It works on 328p (when selecting the  standard Arduino UNO board from the Arduino IDE), but cannot get into m32u4, although it should have same memory size. I know the Arduino Micro comes with a much larger bootloader, however I have uploaded the hex file through ISP, so the bootloader should be overwritten, isn't it?
by eliminating few code lines it works  fine.
Datasheet is  reporting  a flash memory capacity of 32k, so it should still be ok.
I am using the Arduino IDE to compile and avrdude then to upload the hex which is generated from the IDE, without the bootloader via command line
it seems a linker  problem, however I  am not very familiar with the options to use when excluding the bootloader.

Avrdude does not give me any error when uploading the .hex file and the flash verification checks ok, although Arduino IDE does show "text section exceeds available space in board. Sketch too big". The weird thing is, this message is shown on both cases when the sketch works and when it doesn't, so I guess this is only an error from the IDE because it assumes I am uploading through it, including the bootloader.
Any suggestions please?


however I have uploaded the hex file through ISP, so the bootloader should be overwritten, isn't it?
The bootloader was erased, but the BOOTRST configuration fuse is still programmed:

and the Arduino IDE is still configured to fail compilation if the sketch size exceeds the application section (as is the correct thing to do wih the BOOTRST fuse programmed):

It is possible to use the full flash memory capacity of the ATmega32U4 for your sketch, but you'd need to use your ISP programmer to change the BOOTRST fuse and also change the value of the upload.maximum_size build property in the boards.txt entry for your board

With most AVR chips, there is a nice 3rd party boards platform that provides this capability for you, but I'm not aware of one for the ATmega32U4. So you might need to make the modifications yourself. Rather than editing boards.txt directly, you could either add a boards.local.txt file with your modifications:
Just remember to save your file somewhere safe so it doesn't get lost the next time you update to a new verison of Arduino AVR Boards.

Or better yet, make an extension boards platform for your custom board definition. Because you can reference the core library, core variant, and tools from the Arduino AVR Boards platform, your extension platform can be very minimal:



Thanks a lot Pert,

indeed the hfuse  was set to 0xd8, which I guess is the default value for a new board. The  sketch worked once changed to 0xd9 !
As for the board definition, as a quick fix I just changed the micro.upload.maximum_size and the micro.bootloader.high_fuses value in boards.txt for now, but I will follow your advice for the future by creating a dedicated board definition.

Btw, the software reset implemented as a watchdog function (wdt_enable(WDTO_15MS);) didn't work anymore on Micro, perhaps there is a mismatch of constant declarations on Micro (?!) or is this the effect of not having updated properly the board definition file?
For now I used a different implementation for the reset (the "jump to 0" version), which works ok, but I am afraid other side-effects are arising while examining the whole functionality of the code later on.


I am trying to keep the watchdog version of my software_reset routine because I also use the WATCHDOG for the normal purpose.
here my findings:

Just for testing I have created a "skimmed" version of my code keeping the most vital functionalities, so that it compiles and fits on a standard Micro Board with Bootloader.
On this board, the software_reset routine works as it should, restarting the code from the Setup() routine.
When uploading this same skimmed code through ISP on the Micro board without Bootloader (either using the Arduino through programmer or with the avrdude through CLI), the software_reset causes the whole program to halt (or at least, it does not show any reaction anymore). I guess the watchdog interrupt is redirecting to a location different from 0, because when instead I replace the watchdog with the "jump 0" version of the software reset then it works fine.

I have tried to dig into the wdt.h code, however I could not find anything obvious that would relate to this behaviour.

Reading back the fuses after programming confirm they are still good,
The only difference from the two boards is the BOOTRST on the hfuse setting, all other fuses are identical.

On the Micro Board with Bootloader:
Fuses OK (E:CB, H:D8, L:FF)

On the Micro Board without Bootloader:
Fuses OK (E:CB, H:D9, L:FF)

My understanding is that when the BOOTRST is not set, then the BOOTSZ1 and BOOTSZ0 are ignored, so the start of the code should be 0 and the full memory is available for the code, is this correct or has the watchdog implementation its own starting point depending on the platform selected?
Thanks for any illumination


Nov 24, 2020, 02:56 pm Last Edit: Nov 24, 2020, 03:00 pm by daruler
OK! I found the answer in this topic, possibly  helpful in the future for everybody else having the same issue:


There was nothing wrong with the wdt.h, nor the fuse settings or boards.txt,
just my wrong assumption that the watchdog was disabled after reset.
Now the sketch works fine by changing back the WATCHDOG timeout on the first line of Setup()
(obviously my loop() took longer than 15ms to run, so it was stuck in a continuous reset)


Thank you for taking the time to post an update with your solution. I'm sure those who find this thread while searching for a solution to the same problem will be very grateful.

This is tricky because we're accustomed to the bootloader handling this for us (except for the bad stock bootloader on some boards like the Pro Mini and old Nanos as mentioned in that article), but once you erase the bootloader you must handle it in the sketch.

Go Up