Failed to make encryption work on a barebone ATMEGA328P

[Encrypt]

According to that post, it seems there is a high correlation between the fuses value and the fact that security may or may not work.

Here is the boards.txt file I got from the official "Arduino on a breadboard with internal 8MHz clock" bootloader:

##############################################################

atmega328bb.name=ATmega328 on a breadboard (8 MHz internal clock)

atmega328bb.upload.protocol=arduino
atmega328bb.upload.maximum_size=30720
atmega328bb.upload.speed=57600

atmega328bb.bootloader.low_fuses=0xE2
atmega328bb.bootloader.high_fuses=0xDA
atmega328bb.bootloader.extended_fuses=0x05

atmega328bb.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb.bootloader.unlock_bits=0x3F
atmega328bb.bootloader.lock_bits=0x0F

atmega328bb.build.board=AVR_ATMEGA328BB
atmega328bb.build.mcu=atmega328p
atmega328bb.build.f_cpu=8000000L
atmega328bb.build.core=arduino:arduino
atmega328bb.build.variant=arduino:standard


atmega328bb.bootloader.tool=arduino:avrdude
atmega328bb.upload.tool=arduino:avrdude

Do you have any clue @Anticimex / @mfalkvidd?

[Anticimex]

@encrypt sorry no. There is no direct dependency between the security functionality and avr fuses. Atsha communications and some timeouts do expect the clocks to be working at expected rates though so the concept of time is valid. If the core clock is not matching what the preprocessor flags specify (F_CPU) then there could be problems.
Perhaps your device is not really running @8Mhz?

Perhaps you could test running a simple sketch that prints something at a specific pace and match that with a "real" clock. For example printing something every 10s specified by some delay or wait function and measure that that is reasonably accurate.

I would expect that if the MCU is not executing at the speed F_CPU specifies, a thing like delay(10s) would not really delay for 10s.

[Anticimex]

@encrypt but I still do not get how the bootloader could cause you to get tampered eeprom data.
Unless the fuses also affect eeprom writes of course.

[Encrypt]

@Anticimex: I have just found that there is an EESAVE fuse on the ATMEGA328P which prevents the EEPROM from being erased whenever a new sketch is pushed to the microcontroller.

It seems to be the root cause of the issue since I've found references in other posts of the MySensors forum to that problem.

I'll test that now and let you know.

[Anticimex]

@encrypt ah, that would indeed explain a lot and especially the tampered indication.
If true, I'll see if I can add that to the troubleshooting section to the documentation.
I was not aware of this fuse.

[Encrypt]

IT WORKS @Anticimex !!! :the_horns:

The issue was indeed the EESAVE fuse not set, which caused the EEPROM to be erased after each sketch upload.

Here is my modified boards.txt file:

##############################################################

atmega328bb.name=ATmega328 on a breadboard (8 MHz internal clock)

atmega328bb.upload.protocol=arduino
atmega328bb.upload.maximum_size=30720
atmega328bb.upload.speed=57600

atmega328bb.bootloader.low_fuses=0xE2
atmega328bb.bootloader.high_fuses=0xD2
atmega328bb.bootloader.extended_fuses=0x05

atmega328bb.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb.bootloader.unlock_bits=0x3F
atmega328bb.bootloader.lock_bits=0x0F

atmega328bb.build.board=AVR_ATMEGA328BB
atmega328bb.build.mcu=atmega328p
atmega328bb.build.f_cpu=8000000L
atmega328bb.build.core=arduino:arduino
atmega328bb.build.variant=arduino:standard


atmega328bb.bootloader.tool=arduino:avrdude
atmega328bb.upload.tool=arduino:avrdude

So, basically, for people coming here in the future:
Follow the tutorial https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard to flash the bootloader of your ATMEGA328P but replace the given boards.txt file (in the breadboard-1-6-x.zip archive) by the one above.

A useful link to calculate the fuses values: http://www.engbedded.com/fusecalc/

Thanks for your help @Anticimex, @mfalkvidd and @kimot :)

[Anticimex]

@encrypt great news! Thanks for joining the community and for your troubleshooting. This information will be compiled into the docs for future reference. Happy signing :spock-hand:

[tekka]

@anticimex @Encrypt That's a bit odd and certainly specific to the bootloader you're using (ATmegaBoot): AVRdude does (at least with optiboot) a page erase (vs. chip erase where EESAVE has an effect). I do not have the EESAVE fuse bit set and no issues with erased eeprom when loading a new sketch, also see below:

Arduino Uno with optiboot:

uno.bootloader.tool=avrdude
uno.bootloader.low_fuses=0xFF
uno.bootloader.high_fuses=0xDE
uno.bootloader.extended_fuses=0xFD
uno.bootloader.unlock_bits=0x3F
uno.bootloader.lock_bits=0x0F
uno.bootloader.file=optiboot/optiboot_atmega328.hex

High fuse (0xDE) does not enable EESAVE.

[Encrypt]

Hello @tekka and thank you for your remarks!

Your input makes questions come to my mind:

1. What is the difference between Optiboot and the bootloader given in the Arduino tutorial? I am quite new to the world of microcontrollers and I don't know much for the moment, I simply use what is working, eh eh :P

2. The configuration you gave here doesn't use the internal 8MHz clock, therefore it doesn't fit my needs here, eh eh. Could I just use the "regular" Arduino Uno bootloader and set the proper fuses values in the boards.txt file to use the internal 8MHz clock?

3. You are saying that it's actually optiboot which does the page erase and not avrdude? I believed there the "chip erase" instruction is the only instruction possible to erase the flash, handled by avrdude. And according to the ATMEGA328P datasheet (page 297), I have understood that any "chip erase" instruction will also erase the EEPROM if the EESAVE fuse isn't set. That operation seems to be mandatory too as they say: « A Chip Erase must be performed before the Flash and/or EEPROM are reprogrammed ». So, how does Optiboot / avrdude handle that in such a configuration?

Finally, it seems there is no tutorial in the MySensors documentation explaining how to build a project using a standalone ATMEGA328P and which bootloader to choose (there are a few discussions though). It could be worth creating a tutorial / post about that and I could contribute to it of course :)

[tekka]

@encrypt I may have an idea what's going on here: Are you programming a new sketch to your barebone AT328p via ArduinoISP or any other means of serial (=SPI) programming? Programming via bootloader (ATmegaboot or optiboot) requires a FTDI adapter and will only do page erases while leaving the eeprom untouched.

[Encrypt]

Hi @tekka!

I'm indeed programming the ATMEGA328P using an Arduino Uno transformed as ISP with the ArduinoISP sketch.

I've wired the circuit exactly as shown on the first picture of the tutorial here: https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard. I used the same circuit to burn the bootloader and to upload my sketches.

Your remark makes me wonder: do I really need a bootloader at the end?

[tekka]

@encrypt Ok, this explains your issue: programming via ISP will do a chip erase and hence the EESAVE fuse setting is critical for e2p persistance. The most common use case is programming via serial bootloader (e.g. optiboot, atmegaboot, etc.) which only does page erases and leaves the rest untouched. To answer your question: If you're using an ISP programmer you do not need a bootloader.

[mfalkvidd]

I thought the bootloader is overwritten when using ISP? So "you don't need a bootlader" is slightly incorrect, you can not have a bootloader when using isp?

[tekka]

@mfalkvidd The Arduino builder generates two .hex files, one of which contains the bootloader as specified in boards.txt. Depending on the flashing settings you may burn the sketch only or the sketch + bootloader, however, the bootloader is not needed for ISP programming.

[mfalkvidd]

@tekka I see. Thanks for explaining.