Confirm boot lock bits are wide open on devkit?

Probing my devkit with the following:

avrdude -c avr109 -pm32u4 -P /dev/cu.usbmodem1431 -U lock:r:x:h -v

The resulting file is 0xff, which seems that BLB01/02/11/12 are all 1… which would mean “No restrictions for SPM or (E)LPM accessing the Application section”… am I understanding this correctly?

I should point out that this is the default on the 32U4RC (are we RC?). I was just assuming the bootloader would be protected by default from the application reprogramming it, but it does not seem like this is the case. So unless I’m mistaken you should be able to program a new bootloader via USB if you are very very careful. You’d just have to install a sketch that itself acted as a USB programmer (vs the bootloader serving this purpose) and then refreshed the bootloader…

Likely not, since we’ll be using an external crystal.

~ avrdude -c avr109 -pm32u4 -P /dev/cu.usbmodem1431 -U lock:r:x:h -v
...
...
avrdude: reading lock memory:

Reading | ################################################## | 100% 0.00s

avrdude: writing output file "x"
...
...
~ % cat x                                                             
0xff

So seems production Arduboy is also wide open… the bootloader is free to reprogram itself. :slight_smile:

By “production” do you mean the Kickstarter production units, or the retail production units?

Kickstarter units will have “1 of 10000” printed on the back (and may have the RGB LED reversed) and likely have the bootloader unlocked.

Retail units will always be white, won’t have “1 of 10000” on the back, will have the RGB LED installed correctly, and are supposed to have the bootloader locked.

I have only Kickerstarter units, sorry for any confusion. Can someone test a production unit? You need AVR dude… the avrdude command above will write the lock bit to a hex file. I’ve used the Arduino IDE’s terminal to trigger the bootloader… just open terminal, close terminal… jump to a console and run avrdude.