Yun - bootloader sketches > 87% of program memory lock up Yun RESOLVED

Hello all,

Got a problem. I modified my boards.txt to give me a 32k Yun. I also modified the merge-with-bootloader file on the Yun to make it do nothing. Trouble is, if my sketch gets to >87% of the available memory size weird things happen. Either it uploads over the air but the sketch won't start until I power cycle the Yun or I lose the ability to use the reset button. I have to power down the whole yun. reupload a piece of working code, reduce the size of my new code to <87% of program memory then it will work again

Have I screwed up somewhere. Do the default fuse settings somehow always reserve the first 4k for the boot loader so my code is starting at a higher address?

Any ideas would be much appreciated. I really need the 32k.

P.S its not a heap/stack issue. All variables are declared globally from the outset and at compile the Yun reports:

Global variables use 1,266 bytes (49%) of dynamic memory, leaving 1,294 bytes for local variables. Maximum is 2,560 bytes.

So plenty of space there.

Addendum. on further testing the issue appears less to be with the size of the code any more the flaky behaviour of the reset button. Sometimes it works as expected. Sometimes it requires a double press. sometimes it doesn't work at all and leaves the sketch stuck?

Sometimes the sketch uploads over wifi, sometimes it seems to lock up the Yun meaning I need to upload blink then reupload the sketch

I really think we could do with the ability to run the Yun without the bootloader via wifi uploads as a standard feature of the Yun without all this jiggery pokery.

You really need to provide more information about what it is your are trying to do.

What's the sketch you're trying to run. What is the process the Yun is doing with information provided from the sketch. There really is no info provided to help you figure this out.

Afraid I can't post the sketch online as it contains proprietary algorithms which I can't put in the public domain but trust me. the code itself is pristine. it doesnt matter what I substitute in to make the sketch over 87%. as soon as I hit that the uploads and reset become flaky.

So my guess is its not the code. I mean if it was an arduino o running buggy but basic code we would still expect the reset button to be a get you out of jail free card 100% of the time. Something which can be 100% relied on to restart it. Similarly the code itself is irrelevant if the process of uploading it sometime locks up the yun.

The issue seems to be something more to do with the way the Yun handles resets without a bootloader?

Seems this guy has the same issue

http://forum.arduino.cc/index.php?topic=240239.msg1804270#msg1804270

Possible solution.

I was doing a bit of digging on how the Yun reset button works.

http://www.procyonengineering.com/embedded/avr/bootloader/

If I read it correctly when the 32u4 on the Yun resets, the default 32u4 fuse bits for the Yun as used in run-avrdude (Low 0xFF, High, 0xD8, Extended 0xFB) tell it to jump first to the boot reset vector which should be the starting address of the bootloader.

I don't understand enough about the the ATMega32 series of microcontrollers but gleaning a little from here

http://winavr.scienceprog.com/general-avr/avr-microcontroller-memory-map.html

It would appear the boot vector address is at the top end of the flash memory rather than at the beginning.

So what I suspect is happening is this

1.) I compile for a 32k board
2.) I flash it over the air by disabling the merge with bootloader.
3.) When I press reset the 32u4 attempts to jump to the bootloader address expecting to find boot code there.
4.) Instead it finds an arbitrary line of my code which causes it to lock

So after a little playing with this useful tool AVR® Fuse Calculator – The Engbedded Blog

I have determined that for me the correct fuse bits (Both preserving EEPROM through the chip cycle and disabling the the BOOTRST feature) should be Low 0xFF, High, 0xD1, Extended 0xFB)

If I have this correct on reset my code should then happily jump to instruction 0x0000 on the reset line being triggered.

If my thinking is correct its a miracle i've ever managed to get my sketch to boot at all

Just an update. My previous theory on changing the fuses worked.

Can you share your discovery making a brief paragraph on the playground page? Arduino Playground - Yun

mearsy25:
Just an update. My previous theory on changing the fuses worked.

@mearsy25 if this really works, I can say only one thing, I love you! :smiley:
But I have one question for you. How did you know which settings on AVR® Fuse Calculator were correct?
Because the default settings on the calculator don't give default fuses (0xff, 0xd8, 0xfb).
Which setting did you changed?

EDIT: I realized which - "Boot Reset vector Enabled" and "Preserve EEPROM memory through the Chip Erase cycle". Sorry :blush:

Yun= AR9331+ Arduino Leonardo

Arduino Leonardo

Flash Memory 32 KB (ATmega32u4) of which 4 KB used by bootloader

Arduino Mega 2560

Flash Memory 256 KB of which 8 KB used by bootloader

Arduino Due

Flash Memory 512 KB all available for the user applications

Running off program memory of Yun.

Upgrade it to

AR9331 + Arduino Mega 2560

http://forum.arduino.cc/index.php?topic=241259.msg1733572#msg1733572

AR9331 + Arduino Due

http://forum.arduino.cc/index.php?topic=241259.msg1731074#msg1731074