Bricked help needed [Solved-ish]


(ET) #1

ok so after a day of messing around with code i thought i would try a new game. i loaded up Sirene to give it a try… now she is the only game i can play.

flashlight mode and the reset button do nothing. :frowning:

plz help


(Mike McRoberts) #2

Try uploading a blank sketch from the Arduino IDE.


(ET) #3

Ok read that big files can cause this and that the rest button is a fine window. got reset button to work after probably 20 tries. kind of spammed upload with ctrl+u

… what was in system that caused this Sirene game from Team ARG, using IDE ver 1.8.1

what fixed it Hello World uplading after reset about 20 times. still using IDE ver 1.8.1.

is there a way to protect the boot?
TY


(Mike McRoberts) #4

Did you upload the latest version of Sirene or an older version?

The Bootloader (if that is what you mean) cannot be damaged by uploads or resets.


(ET) #5

ok so i guess the Bootloader reset button is just a short window of pressing.

i got Sirene from this link http://www.team-arg.org/srn-downloads.html

then went to GitHub and downloaded zip


(Kevin) #6

The boot loader window is pretty short at 6 seconds. I wish I had made it longer but it’s the default for Arduino.

It sounds like potentially the latest version of Arduino may be the issue?

The actual bootloader is protected to use the reset button, other than that it has to be done by the software by each developer. Games based on the Arduboy2 library have something called “flashlight mode” where you hold the up button while resetting it to force it into bootloader without the timing window of the reset button. Team ARG was in the process of switching their games to the Arduboy2 library (which also has improved compatibility with the latest versions of Arduino) and it is managed by @MLXXXp.

Ping to @JO3RI if he has this on the radar or not?

Glad you were able to get it reset!


(ET) #7

in case it helps,

Mystic Balloon works

Sketch uses 28190 bytes (98%) of program storage space. Maximum is 28672 bytes.
Global variables use 1703 bytes (66%) of dynamic memory, leaving 857 bytes for local variables. Maximum is 2560 bytes.

Sirene does not

Sketch uses 28280 bytes (98%) of program storage space. Maximum is 28672 bytes.
Global variables use 1796 bytes (70%) of dynamic memory, leaving 764 bytes for local variables. Maximum is 2560 bytes.

I guess this only matters if it truly is a memory issue.


(Scott) #8

The process was completed weeks ago. The latest versions of all Team A.R.G. games and demos use the Arduboy2 library.


(Scott) #9

Program memory use is not a factor. It’s a large amount of RAM use (what Arduino reports as dynamic memory) that causes the bootloader problem.


(Scott) #10

@bateske, You always tend to jump on the latest version of Arduino as introducing problems. The compiler used hasn’t changed since Arduino 1.6.10. Versions from 1.6.10 to the latest 1.8.1 all produce exactly the same code.

What has changed is the Arduboy2 library. The latest version can add a couple of hundred bytes to the program size of a sketch. But program size doesn’t affect the bootloader problem.


(Kevin) #11

If the game uses Arduboy 2 library, then you should be able to use the Flashlight Mode to reprogram it by holding the up button when you turn it on.

http://community.arduboy.com/t/how-to-use-flashlight-mode-to-fix-bricked-arduboys/


(ET) #12

i tried this method. i was able to use the flash light but no joy on the re-upload. i recommend some one with more XP then me try to download the game and try it… if its only happening to me then i need to know that so i can try to find what it is im doing wrong.


(Scott) #13

Even if the game uses the original Arduboy library you can use flashlight mode. Flashlight mode is in the Arduboy library. The only things the Arduoby2 library adds is that the display is lit as well as the RGB LED, and you can turn off the flashlight and continue with the game by pressing the DOWN button instead of having to reboot.


(Kevin) #14

I used the current version of arduino and library and was able to successfully uninstall the game. So that Sirene itself doesn’t seem to be the problem.

However… I had the problem with the 3d teapot demo (compiled a couple months ago), I couldn’t get it to go into bootloader mode, even with flashlight and had to use the reset button.

Then I reinstalled the teapot demo with current sources and it won’t auto-reset, but flashlight mode works.

The auto-reset problem is strange actually the 3d teapot demo only uses 74% of ram. Sirene too, it only uses 70%.

If it’s not a ram capacity issue is something dynamically mapping at run time to the wrong address?


(Scott) #15

No, it’s not only you. I get exactly the same thing.

My experiments show that if Sirene is compiled with Arduboy2 library version 3.1.0 then you need to use the reset button to load a new sketch. Flashlight mode doesn’t work.

If you compile Sirene with Arduboy2 library version 3.0.0 then there are no problems uploading a new sketch.

The differences are:

Arduboy2 3.0.0

Sketch uses 28220 bytes (98%) of program storage space. Maximum is 28672 bytes.
Global variables use 1788 bytes (69%) of dynamic memory, leaving 772 bytes for local variables. Maximum is 2560 bytes.

Arduboy2 3.1.0

Sketch uses 28280 bytes (98%) of program storage space. Maximum is 28672 bytes.
Global variables use 1796 bytes (70%) of dynamic memory, leaving 764 bytes for local variables. Maximum is 2560 bytes.

So the extra 8 bytes of global variables is somehow causing the problem. The fact that it can’t be recovered using flashlight mode means the RAM has been corrupted before flashlight mode is entered.


(Scott) #16

I can only guess that a particular global variable is being initialised before flashlight mode is tested for, with a value and location that upsets the bootloader.

I don’t know if there would be a way to have something similar to flashlight mode that runs before global variables are initialised.


(Kevin) #17

What about setting the magic number manually to what it’s supposed to be within the flashlight loop?


(Scott) #18

Good idea! I’ve never investigated exactly how the magic number works, but if it’s a known value at a known location, flashlight mode could save whatever is there and replace it with the magic number. If the user presses DOWN to exit flashlight mode and continue with the sketch, the saved value could be restored before doing so.

Anyone (maybe @Dreamer3?) with additional knowledge about exactly how the magic number works, do you think this is possible? If there’s no response, I’ll look into it myself when I find the time.


(Kevin) #19

They stick it at the end of ram using a function called RAMEND.

This kind of all came about from this thread almost 2 years ago:

And you can see the change they made here:

So from what I can tell we should be storing 0x7777 at RAMEND-1?

Or is it possible it is using location 0x0000??? If we are actually using an older bootloader, this is where arduino would look, and not at 0x0800?

// Backup ram value if its not a newer bootloader. // This should avoid memory corruption at least a bit, not fully

Are we in the “not fully” category? I swear we are using the newest bootloader from after this fix…


(Scott) #20

@bateske,
I did a bit more digging and discovered that RAM addresses don’t start at 0. RAM starts at address 0x100. Therefore, if the bootloader is storing a magic number at address 0x800 then this is really only 0x700 bytes into RAM space.

0x700 is 1792 in decimal. This would explain why Sirene is OK when compiled with Arduboy2 V3.0.0 because it only uses 1788 bytes of global variables. However, Sirene has problems when compiled with Arduboy2 V3.1.0 because it uses 1796 bytes of global variables, which when initialised would overwrite the contents of address offset 1792.

So, this is good evidence that the Arduboy bootloader is storing the magic number at RAM address 0x800.