Preventing writes to the bootloader area using software is totally unnecessary as long as the lock bits have been set properly.
If you have the capability to burn the bootloader, you also have the capability to properly set the lock bits. If you use the Arduino IDE to burn the bootloader, this will be done automatically.
The last part is usually the problem. You can easely forget to set them (even my recently purchased Arduboy didn’t have then configured)
What about If you don’t have the capability and the bootloader was burned by someone else who didn’t set the lock bits properly? You’d have to go through some trouble to get it fixed.
Hmmm… this taking about bootloader protection and lock bits. just gives me an Idea: I’ve freed over 1K of space in the bootloader. With just software bootloader protection I could make that area unprotected. That would be great for a selfprogramming bootloader extension or extra space
I must admit, there have been many cases of the lock bits not being set, even on newer Arduboys.
Happened to me with my first one.
RIP my 1st arduboy, have no programmer to bring you back to life. qq
I you have the capability to burn the bootloader, then forgetting to lock it isn’t a problem. You can always just burn it again if it gets corrupted.
If someone else burns the bootloader for you, then it should be their responsibility to make sure it’s protected. If not, it’s on them to correct the problem (which the Arduboy organisation has be very good about dealing with).
The proper way of handling the problem is not to add code that would be useless if the hardware is set properly. It should be handled by making sure the problem doesn’t occur, such as by using a script that both does the burning and sets the locks in one operation. Or, by using the Arduino IDE to burn the bootloader.
Well I’m also keeping in mind that the bootloader can be used for the regular Arduino’s Leonaro, Micro ProMico,etc.
It’s a 30 byte protection now that only protects the 1st 3K of the bootloader allowing the last 1K to be self programmed if the bootloader bit’s are not set. I’ve also dubbed the bootloader ‘Cathy3K’ now because of it taking up 3K
But back to the Arduboy features. it’s in!
I’ve successfully added the streaming to display code, button reading and a little USB connector sprite to display in bootloader mode just for fun 
Bootloader size is at 2988 bytes now.
bootloader hex file and python demo at:
http://mrblinky.net/arduboy/arduboy-streaming-bootloader.zip
Streaming is quite simple:
Set current address to 0 using command ‘A’,0x00,0x00 wait for response byte
8 times: write 128 bytes of display data using command ‘B’,0x00,0x80, ‘D’ followed by the 128 bytes of display data and wait for response byte
Reading the buttons is done using the hardware version command ‘v’ (lover case)
write command ‘v’, read response byte. if not equal ‘?’ (normal bootloader response) read another response byte.
button_AB_state = ResponseByte1 -‘1’, D-Pad_state = ResponseByte2 - ‘A’
Still need to work on command 'x to control the LEDs. So no control of the LEDs yet.
If you expect this to be usable with an Arduino Micro, make sure you have defines and/or code to take into account the fact that the polarity of the TX and RX LEDs is reversed. You set their pin high to turn them on rather than low.
Thanks I already have. Undefine ARDUBOY and you get ordinary optimized bootloader for Leonano/Micro, Change DEVICE_PID to 0x0037 and the Rx/Tx Led polarity is changed. Bootloader size is 2730 bytes for the ordinary version. Will make it public once I’m done with adding features and cleaned the source up.
I think it’s possible to create a new board type to define an Arduboy with a 3K bootloader and have it leave the bootloader unlocked if burned using the IDE. This would allow sketches to be 1K larger.
However, this may lead to complaints for any sketches taking advantage of this:
I’d love to be able to play SuperBigGame but it will only work on an enhanced bootloader Arduboy and mine’s a regular one 
Is that possible? the free 1K is after the bootloader (has to be because of the vectors)
If this bootloader would end up on official Arduboy’s It would be a good reason to get another one 
But seriously, I dislike the idea too of having games that require specific hardware (unless the dependency was SD Card)
I really haven’t thought much about the uses for it yet. It could also be wasted on customizable bootscreen to personalize your Arduboy 
I mainly started the optimalisation project to see if enough space could be freed to add SD card code. But as always I see and get nice ideas and get distracted 
But I think these 258 bytes of Arduboy specific code turned out quite nicely (I’ll need some more bytes for the LED control but It will be under 3K total).
Oops, sorry. You’re right. I quickly looked at the datasheet and misread the table. I thought the bootloader was at the start of flash, not the end 
How did you reduce the size so? When I looked at this a while back the C code seemed pretty tight to me… I think the default compile has like 100 free bytes or something.
I can’t handle how awesome this all is, the amount of work that’s going into this is just incredible 
By assembly coding. I started by building caterina bootloader then reversed it to assembly and made it assemblable again, verified binaries as confirmation and then went to optimizing using byte crunching skills.
I’ve had a idea 
I think there’s a way to do this but it would require extra effort to organise and maintain the bootloader.
The bootloader would be divided into two sections, which I’ll call the core and support sections. The core section would reside in the flash area actually reserved for the bootloader, which would be reduced from a 4K to a 2K size. The support section would then be placed immediately before the bootloader area.
You would put as much code as possible in the 2K core section, including any code containing the SPM instruction (which can only be executed from the bootloader area). Additional code required beyond 2K would be written as subroutines and located in the support section. So, from a hardware point of view there would be a 2K bootloader but it would be calling subroutines, as necessary, in the application area just below it. You could software protect writes to the support area, as you’ve currently done.
A new board type would be created that allowed sketch code to go up to the start of the bootloader support area (or maybe the closest 1K or 512 byte boundary so as to leave a bit of headroom for future bootloader size increases). This board type could specify either locking the bootloader area or leaving it unlocked, as desired.
Another thought:
The additional enhancements that have been, or will be, made to control the display and RGB LED, and read the buttons, means that the bootloader has to initialise this hardware. If the bootloader made sure that, before jumping to the application, all the hardware was initialised identically to the way it’s currently being done in the Arduboy2 library’s bootPins(), bootSPI() and bootOLED() functions, then this code could be removed from the Arduboy2 library. The Arduboy2 library could do this using conditional compile tests, based on the new board type. This would make even more space available for the actual application.
I get the idea of splitting the bootloader up in a core and support section (this makes it possible to put api calls in the vector table using RJMPs). But I don’t get why you want to take space away from the application area. (<0x7000) to gain more space after the bootloader (0x7800-0x7FFF)
The support section would still be mandatory and should also be protected otherwise the bootloader can still be bricked.
The ‘core’ caterina bootloader is 2718 bytes atm. Arduboy code 354 bytes. I could move some of the non essential command stuff up but that doesn’t get me close to 2K for a core (that would be a Cathy 2K challenge for later)
On Another thought,
Sounds good. I’m not sure I do all initializing that Arduboy2 does. But the buttons LEDs and OLED are initialized and the display routine could be used as well. I’ll do a check later to see if I can add complete initialisation. I’m currently at exactly 3K.
Hmm now that you mention freeing code for more Application space. I’m thinking about that 3K USB code. I’m wondering how small a bare minimum ‘enter bootloader through USB’ would be…
Oh man! I think I’m not getting to work on SD card support for a while … 
Back to the bootloader. I’ve updated the zip file with a new version of the bootloader and streaming demo. This new version support the set LED AVR910 command to control the RGB breathing, RxTx transfer status and turn OLED display, RGB LEDs and Rx,Tx LEDs on and off. I’ve also changed the OLED display code to use page/column mode. So it works with other OLED displays too.
http://mrblinky.net/arduboy/arduboy-streaming-bootloader.zip
I’m not sure what you’re saying here.
Let’s talk in terms of words instead of bytes, to match the datasheet. The bootloader area can be set to 4 sizes: 256, 512, 1024 or 2048 words.
Currently the bootloader is set to the maximum size of 2048 words (4096 bytes), which means it starts at address 0x3800 and ends at address 0x3FFF. The application area is thus 0x0000 to 0x37FF.
My proposal is to set the fuses for a 1024 word bootloader area size, from 0x3C00 to 0x3FFF. The application area is then increased: 0x0000 to 0x3BFF (an extra 1K words or 2K bytes).
However, you can’t squeeze the bootloader down to fit in 1K words. So what you do is put as much of it into the 1K word bootloader area as possible and move the rest into subroutines at the top of the application area from 0x3BFF downwards. If you need 1536 words total (3K bytes), then this support (maybe extended is a better term?) section would be 512 words from 0x3A00 to 0x3BFF. The application area that could be used by sketches would be 0x0000 to 0x39FF (a gain of 1K bytes over the current amount).
This table shows the current and proposed program flash memory maps (in words):
| Area | Current | Proposed |
|---|---|---|
| Sketch (Application) |
0x0000-0x37FF | 0x0000-0x39FF |
| Bootloader support (Application) |
N/A | 0x3A00-0x3BFF |
| Bootloader core (Bootloader) |
0x3800-0x3FFF | 0x3C00-0x3FFF |
Ahhhh! Now I see what you mean! (I was blinded for a moment) Great idea! It’s the way to extend sketch space. I’ll do some rearranging
Welp, I guess that’s this project killed:
