Retrieving AVR FLASH section size from the command line

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

Freaks,

I've got a little scripting problem I was hoping someone more familiar with the binutils and command line could help me with.

One problem that's been plaguing users of my bootloaders is that they have trouble figuring out the correct starting address of the bootloader, which they have to plug into the makefile in order to relocate the .bootloader section correctly. This is actually just a simple formula:

Quote:
(FLASH_SECTION_SIZE_BYTES - BOOT_SECTION_SIZE_BYTES) * 1024

But since GCC requires a byte address yet AVRStudio currently reports word addresses for the bootloader sections, I thought it would be easier if I could make this automatic.

Right now I've got this partial solution:

# Starting byte address of the bootloader, as a byte address -
# computed via the formula:
#   BOOT_START = ((FLASH_SIZE_KB - BOOT_SECTION_SIZE_KB) * 1024)
#
# Note that the bootloader size and start address 
# given in AVRStudio is in words and not bytes,
# and so will need to be doubled to obtain the byte
# starting address needed by AVR-GCC.
FLASH_SIZE_KB        = 128
BOOT_SECTION_SIZE_KB = 4
BOOT_START           = 0x$(shell echo "obase=16; ($(FLASH_SIZE_KB) - $(BOOT_SECTION_SIZE_KB)) * 1024" | bc)

Which just requires that the user alter the FLASH_SIZE_KB value, as the bootloader section size should be constant for each bootloader unless I make a major revision.

I'd still like to automate the extraction of FLASH_SIZE_KB from the selected AVR model however. Does anyone have a good idea for my makefile, so that the value of FLASH_SIZE_KB can be determines automatically from the MCU setting?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Are you making the assumption they'll always have BOOTSZ=00 and be using the largest BOOTSZ area?

Surely the idea is that you build the bootloader, work out what's the smallest BOOTSZ setting it will fit into, set the BOOTSZ to that and then rebase the code build to that base address?

I'm not sure how you can automate that?

As it stands I don't see how it's any better having them set:

BOOT_SECTION_SIZE_KB = 4

which they are going to have to look up according to BOOTSZ anyway. They might as well just say:

BOOT_START = 0x1C000

using a value taken from the same table where they found the "4K" value.

I guess you could double a word address (as shown in the datasheet) to a byte address for GCC if you thought it might help.

At the end of the day determining the byte/word address of a given BOOTSZ isn't exactly rocket-science, I'd let them work it out. All it takes is clear instructions of how they should interpret what they are reading in the datasheet and specifically where to find that table - I think it's always the last item in the "Bootloader Support" chapter. It may even be true to say that it's always on the page before the "Memory Programming" chapter.

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

I know that the bootloader size will only fit into a 4KB section for all targets, from 8KB to 128KB - it's a LUFA bootloader, and thus I know which AVRs it will be compiled for. The larger AVRs can actually have 8KB sections, but the bootloader itself only needs 4KB.

The end-result for this should be that I can set the bootloader section size in the makefile, document the section size (in words and bytes) in the bootloader documentation, and have it "just work" regardless of target. I don't want to hard-code in a lookup table or similar, since new devices might come out between subsequent LUFA releases.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

When you run XMLCONVERT, the output file has a series of definitions for the bootloader areas. Are they carried over to io.h? (there was a recent thread on that; it seems that some pieces from the .XML are, and some are not. Strange, as I'd assume that the part include files would be based on the Atmel .XML.)

/* ***** DATA MEMORY DECLARATIONS ***************************************** */
#define    FLASHEND        0x1fff  // Note: Word address
#define    IOEND           0x00ff
#define    SRAM_START      0x0100
#define    SRAM_SIZE       1024
#define    RAMEND          0x04ff
#define    XRAMEND         0x0000
#define    E2END           0x01ff
#define    EEPROMEND       0x01ff
#define    EEADRBITS       9



/* ***** BOOTLOADER DECLARATIONS ****************************************** */
#define    NRWW_START_ADDR 0x7000
#define    NRWW_STOP_ADDR  0x7fff
#define    RWW_START_ADDR  0x0
#define    RWW_STOP_ADDR   0x6fff
#define    PAGESIZE        128
#define    FIRSTBOOTSTART  0x1f80
#define    SECONDBOOTSTART 0x1f00
#define    THIRDBOOTSTART  0x1e00
#define    FOURTHBOOTSTART 0x1c00
#define    SMALLBOOTSTART  FIRSTBOOTSTART
#define    LARGEBOOTSTART  FOURTHBOOTSTART

I don't know if it will help--can you use this compile-time stuff, or does it have to be at link-time?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I can use FLASHEND inside the C code, but I also need the starting address in the makefile so that it can be passed to the linker via --start-address= to relocate the entire .text space into the bootloader region.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

I doubt this is worth the degree of automation you desire. You might spend your time just to find out you are getting in way of the thinking variety of the users.

A well-written and -positioned howto should do just well.

JW