ATTINY416 flash can't be *all* BOOT section, right?

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On an ATTINY416 NANO dev board:

The fuses APPEND and BOOTEND are both 0x00 (as seen in the "Device Programming" tool in Atmel Studio 7).  According to the full datasheet, this means that the entire flash is boot section, which seems unfeasible to me - I don't know now the chip can run with no APP CODE.  I have been using the board for dev for several weeks, and never noticed the fuses 'til now, because now I need to reserve a minimal space for APP DATA.  Setting APPEND requires knowing how big BOOT really is.  I did not alter any fuses on this board, and after programming the chip, it runs at power-up.  Are these the factory default values for BOOTEND and APPEND?  Of course it is possible that the tool is busted and is misreading the fuses 8(.

 

 

The description for BOOTEND in the data sheet is unhelpful, owing to the obvious error (unless "whole Flash" and "entire Flash" mean different things):

Bits 7:0 – BOOTEND[7:0]: Boot Section End
These bits set the end of the boot section in blocks of 256 bytes. A value of 0x00 defines the whole Flash
as BOOT section
. When both FUSE.APPEND and FUSE.BOOTEND are 0x00, the entire Flash is BOOT
section
.

 

Surely, if BOOTEND == 0x00, then BOOT must be some default size (?).

Does anyone know how to learn the actual size of BOOT, so that I can set the BOOTEND fuse, so that I can set the APPEND fuse?

 

As always, all commentary is gratefully received.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't see any reason why the flash can't be 100% boot? After all, "boot", "app" and "data" are just flags to set write access rights to the flash.

 

From the datasheet:

Inter-Section Write Protection

Between the three Flash sections, a directional write protection is implemented:

• Code in the BOOT section can write to APPCODE and APPDATA

• Code in APPCODE can write to APPDATA

• Code in APPDATA cannot write to Flash or EEPROM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note that there are "many" old-style AVRs whose flash memory is "all" bootloader section (ie ATmega48.)  They tend to label them "self programming" rather than as having "bootloader support", but they amount to the same thing.  What you lose is the separate and mutual read/write protection fuses.

 

I'm not sure I like the new bootloader scheme, with the bootloader at the start of flash instead of the end.   That means applications need to be compiled with a different start address depending on whether they're aimed at chip with a bootloader, eliminating "bootloader transparency."  (Unless I missed something?)   OTOH, it's nice to have finer granularity of the bootloader size...

 

(it's vaguely similar to ARM Cortex "Privileged" vs "unprivileged" execution modes.  Many applications never use the "unprivileged" mode.)

 

Last Edited: Tue. Feb 26, 2019 - 08:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you.  All true.  But I wish to defend the bootloader against accidents, which is the purpose of the fuse.  Any idea how big the bootloader is in the ATTINY416?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ned Zeppelin wrote:
Any idea how big the bootloader is in the ATTINY416?
If I read it correctly, 512 bytes are allocated.

fuses.h

#include <avr/io.h>

FUSES = {
 .OSCCFG = FREQSEL_20MHZ_gc,
 .SYSCFG0 = CRCSRC_NOCRC_gc | RSTPINCFG_UPDI_gc,
 .SYSCFG1 = SUT_64MS_gc,
 .APPEND = 0x00, // Application data section disabled
 .BOOTEND = 0x02 // Boot section size = 0x02 * 256 bytes = 512 bytes
};

via AN2634 - Bootloader for tinyAVR 0- and 1-series, and megaAVR 0-series

via ATTINY416 - 8-bit AVR Microcontrollers

 

...

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ned Zeppelin wrote:
Any idea how big the bootloader is in the ATTINY416?
Datasheet says this:

 

 

So (as in thread title) the default is that the whole of flash is potentially a bootloader.

 

But the whole point of having the fuse is that it's in your control. You can set it to any value you like if you decide to use a bootloader and make an app/boot split.

 

If you aren't going to use a bootloader then it doesn't matter what value it is set to and 0x00 is as good a default as anything.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Thank you.  It took me a while to get back to this.  This led me to a lengthy dissertation on fuse support in fuse.h.