error in bootloader code for mega328.

Go To Last Post
82 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

*******after all the topic conversation the actual errors points to the source code. See post 52 on page 2. *******

 

 

 

 

I'm using a 328p chip with a USB bootloader from the v-usb project.  Today I had an issue loading my hex I have not ran in to yet. Avr studio says my chip is not full but I'm getting error during my boot flash that implies I'm out of space.  The bootloader says it failed at 0x7080.

 

Avr studio build says I have room left (see below).

I though the calculation included the boatloader space?

  Program:   28704 bytes (87.6% Full)
        (.text + .data + .bootloader)

 

 

If I remove a line of code and compile it flashes fine. Why would the size be reported incorrectly (if that is even my issue)?

 

 

        Size before:
        AVR Memory Usage
        ----------------
        Device: atmega328p
        Program:   28704 bytes (87.6% Full)
        (.text + .data + .bootloader)
        Data:       1227 bytes (59.9% Full)
        (.data + .bss + .noinit)
        Size after:
        AVR Memory Usage
        ----------------
        Device: atmega328p
        Program:   28704 bytes (87.6% Full)
        (.text + .data + .bootloader)
        Data:       1227 bytes (59.9% Full)
        (.data + .bss + .noinit)
        -------- end --------      

 

 

 

 

 

Last Edited: Thu. May 11, 2017 - 01:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Send me an email. bobgardner at aol dot com. I'm in Edgewood/Pinecastle area. Maybe we can collaborate on some problem solving?

 

Imagecraft compiler user

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

If you are writing a bootloader why on earth would you have a memory section called ".bootloader"? A bootloader just moves the entire .text to the BLS

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

I'm not really sure, it was a a open source project I started with. There are 3 parts to this

 

Boot loader

USB driver firmware

Code

 

The USB driver firmware and Code are really one in the same. Maybe the driver is label bootloader, I dont see where this bootloader is defined. I figure it was in the MAKE file but its not there? - I'm using AS6

Last Edited: Mon. Dec 12, 2016 - 03:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was simply referring to:


        AVR Memory Usage
        ----------------
        Device: atmega328p
        Program:   28704 bytes (87.6% Full)
        (.text + .data + .bootloader)

But that all seems very odd. 28K of code? It's clearly not just a bootloader. It looks like a bootloader AND and application being built together - recipe for total disaster if you ask me!

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

right, that  is how I understood your first post.  I agree but what in as6 would be adding this "bootloader". Is that specified in the make file or setting somewhere?  I'm not really sure why that is there but do agree it looks strange. It has always been there. Is there a place to define the memory sections?

Last Edited: Tue. Dec 13, 2016 - 02:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The way you build applications and bootloaders is separately. They should be two totally unrelated projects, each with their own main() and each with their own base address. You only use techniques like ".bootloader" when you simply want to add some flash writing code to an app and so that small part of it needs to be lifted to high addresses so that the SPM opcode can be used. For a true bootloader it's just like a normal app. They both have a ".text" section and the only difference is that the base address of the bootloader is lifted high.

 

If this isn't your own project code it sounds like the original author did not understand this concept.

 

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

The way you build applications and bootloaders is separately. They should be two totally unrelated projects, each with their own main() and each with their own base address. 

and I have precisely  that. I'm not 100% sure on what the addresses are but I do remember having to put that in the the project somewhere. The bootlaoder is at the higher start address and the main part of the application is in a lower address. Avr studio has a habit of moving stuff..

 

You only use techniques like ".bootloader" when you simply want to add some flash writing code to an app and so that small part of it needs to be lifted to high addresses so that the SPM opcode can be used.

From what I have always understood about my project is that the bootloader code (project 1 with its own main) gets put in the higher area and project 2 (also with its own main and the build out put at the top of this post ) gets put in to a specific area on the chip loaded by the bootloader. When I make a chip I load my bootloader then I use the flash tool to upload my project. 

 

This seem to match what you just said? 

 

but you raised a concern about this code

 AVR Memory Usage
        ----------------
        Device: atmega328p
        Program:   28704 bytes (87.6% Full)
        (.text + .data + .bootloader)

 

So is there a concern any longer?

 

The issue I'm having is when I build my project two it calculate this 87% full.  I know for a fact the bootloader is not %23 percent of my chip, more like %8.  but when I use my flash tool it complains. 

 

 

The things that are not clear to me.

This 87%, does that take in to account the boot loader? I say that because there is no way project 2 could know anything about my boot loader (I think). 

I'm not sure I need this .bootloader, I'm pretty sure I use a true bootloader. Both are their own projects. 

How do set this .bootloader, where did it come from, if its not needed could that be my issue. 

 

 

I can not past my output from the bootloader but it says this

device size -00032768

data (28674) exceeds flash size!

flashing 28800 (0x7080) bytes  start at 0

and obviously fails at 0x07000

 

 

If this isn't your own project code it sounds like the original author did not understand this concept.

That or maybe it get mixed up in the shuffle. The original code goes back to 07. I have gone from as4 to 5 to now 6. I would have gone to 7, but I came to the realization there is no point in update so why bother.  Every time AS comes out with a new version it changes stuff. 6 is working ok enough that I'll leave it be. The bootloader is compiled in as4 and the main app in as6 but I dont think that is an issue. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Last Edited: Tue. Dec 13, 2016 - 10:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, here is an extremely simple example to show what I think may be wrong here:

$ cat avr.c
#include <avr/io.h>

__attribute__((section(".bootloader"))) void foo(void) {
    PORTB = 0x55;
}

int main(void) {
    DDRB = 0xFF;
    foo();
}
$ avr-gcc -mmcu=atmega328p -Os -Wl,-section-start=.bootloader=0x7F00 avr.c -o avr.elf
$ avr-objcopy -O binary -j .text -j .bootloader avr.elf avr.bin
$ ls -lh avr.bin
-rwxr-xr-x 1 uid23021 domain_users 32K Dec 14 09:12 avr.bin
$ 

It couldn't get much simpler than this. It's an AVR program with two functions in it. One is main() which will be built, along with the interrupt vectors and other CRT stuff down near location 0. Then there is one function (foo()) which is put into a memory section called .bootloader. The function itself will only be about 8 bytes but when I build I tell the linker to base .bootloader up at a bootloader like address (0x7F00 in this case). Finally I extract a complete program consisting of .text and .bootloader into a binary file. That file on disk is 32K ! In fact:

-rwxr-xr-x 1 uid23021 domain_users 32518 Dec 14 09:12 avr.bin

So I have managed to build something that occupies almost the entire flash of the AVR (admittedly with a big "hole" in the middle) using 2 C functions.

 

I imagine your "87"%" is actually a much smaller app size and then something tagged on "up high" at the end that extends the entire thing to look like it is occupying most of the flash. If, as you say, the AVR already has a bootloader then clearly you cannot have the app using .bootloader too if that really means some SPM routines lifted to the same address space that the bootloader already tries to occupy.

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

Now I don't know your bootloader , the settings programmed etc.

 

But max bootloader size is 2048 Words = 0x1000 bytes that mean starting at 0x7000 !

 

Perhaps the limit is in the setting in the bootloader (how big it could be!)  

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

In the Makefile for the bootloader firmware downloaded from the V-USB link in Post1 there is a configuration section that you are meant to customise for your target AVR.

# Name: Makefile
# Project: bootloadHID
# Author: Christian Starkjohann
# Creation Date: 2007-03-19
# Tabsize: 4
# Copyright: (c) 2007 by OBJECTIVE DEVELOPMENT Software GmbH
# License: GNU GPL v2 (see License.txt)
# This Revision: $Id$

###############################################################################
# Configure the following variables according to your AVR. The example below
# is for an ATMega8. Program the device with
#     make fuse    # to set the clock generator, boot section size etc.
#     make flash   # to load the boot loader into flash
#     make lock    # to protect the boot loader from overwriting

DEVICE = atmega328p
BOOTLOADER_ADDRESS = 7800
F_CPU = 12000000
FUSEH = 0xc0
FUSEL = 0x9f

I've had a go at guessing what you should have entered, do you concur ?

 

The makefile contains a couple of silly errors:

1 The ELF file linker output is ELF format but is named main.bin

2. avr-size is run on the hex file and not the ELF giving less info than it could if it were run on the ELF.

 

After fixing those I get this build:

nigel@E3510:~/Project/freaks/bootloadHID.2012-12-08/firmware$ make all
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -Iusbdrv -I. -mmcu=atmega328p -DF_CPU=12000000 -DDEBUG_LEVEL=0  -x assembler-with-cpp -c usbdrv/usbdrvasm.S -o usbdrv/usbdrvasm.o
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -Iusbdrv -I. -mmcu=atmega328p -DF_CPU=12000000 -DDEBUG_LEVEL=0  -c usbdrv/oddebug.c -o usbdrv/oddebug.o
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -Iusbdrv -I. -mmcu=atmega328p -DF_CPU=12000000 -DDEBUG_LEVEL=0  -c main.c -o main.o
In file included from usbdrv/usbdrv.c:10:0,
                 from main.c:22:
usbdrv/usbdrv.h:223:24: warning: 'usbFunctionDescriptor' used but never defined
 USB_PUBLIC usbMsgLen_t usbFunctionDescriptor(struct usbRequest *rq);
                        ^
usbdrv/usbdrv.h:230:17: warning: 'usbSetInterrupt' declared 'static' but never defined [-Wunused-function]
 USB_PUBLIC void usbSetInterrupt(uchar *data, uchar len);
                 ^
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -Iusbdrv -I. -mmcu=atmega328p -DF_CPU=12000000 -DDEBUG_LEVEL=0  -o main.elf usbdrv/usbdrvasm.o usbdrv/oddebug.o main.o -Wl,--relax,--gc-sections -Wl,--section-start=.text=7800
rm -f main.hex main.eep.hex
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
avr-size main.elf
   text	   data	    bss	    dec	    hex	filename
   1806	     10	     49	   1865	    749	main.elf

As you can see there should be no problem fitting this into the 2K bootloader section.

 

{Captcha: BMSRMPP "Bugger Me, Someone's Reset My Posting Privileges"}

 

 

Last Edited: Wed. Dec 14, 2016 - 06:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

{Captcha: BMSRMPP "Bugger Me, Well Bless My Soul! Someone's Reset My Posting Privileges"}

 The website software settings are being globally adjusted/fine tuned in an attempt to eliminate the spammers who have lately represented more than 50% of new registrations. Everyone is affected.... moderators included. Please be patient while adjustments are being made to everyone's benefit.

 

Thanks,

 

Ross

Ross McKenzie ValuSoft Melbourne Australia

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

IIRC you could get the same effect putting everything in .bootloader :

Binary format is just bytes starting from address zero.

Again, IIRC one can use the .elf to produce a .hex file which does have gaps.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

Ok yes my bootloader make file looks identical, all of your guesses are correct. The bootloader is also flashed to a SMD board and changing it is really out at this point since the product is in the main stream. 

 

This is my output  from the bootloader build.

   ^
		Finished building: .././main.c
		Building file: ../usbdrv/usbdrvasm.S
		Invoking: AVR32/GNU Assembler : 4.8.1
		"C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-gcc.exe" -Wa,-gdwarf2 -x assembler-with-cpp -c -mmcu=atmega328p -Wall -gdwarf-2 -std=gnu99                       -DF_CPU=12000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -I "..\usbdrv" -I "..\."  -MD -MP -MF "usbdrv/usbdrvasm.d" -MT"usbdrv/usbdrvasm.d" -MT"usbdrv/usbdrvasm.o"   -o "usbdrv/usbdrvasm.o" "../usbdrv/usbdrvasm.S"
		Finished building: ../usbdrv/usbdrvasm.S
		Building target: main.elf
		Invoking: AVR/GNU Linker : 4.8.1
		"C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-gcc.exe" -o main.elf  main.o usbdrv/usbdrvasm.o   -Wl,-Map="main.map" -Wl,--start-group  -Wl,--end-group -Wl,--gc-sections -Wl,-section-start=.text=0x7800  -mmcu=atmega328p
		Finished building target: main.elf
		"C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures  "main.elf" "main.hex"
		"C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "main.elf" "main.eep" || exit 0
		"C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "main.elf" > "main.lss"
		"C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "main.elf" "main.srec"
		"C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-size.exe" "main.elf"
		   text	   data	    bss	    dec	    hex	filename
		   1900	     10	     49	   1959	    7a7	main.elf
	Done executing task "RunCompilerTask".
	Task "RunOutputFileVerifyTask"
				Program Memory Usage 	:	1910 bytes   5.8 % Full
				Data Memory Usage 		:	59 bytes   2.9 % Full

 

5.8 + 87  is not 100

but    5.8 + 5.8  +  87 is over 100

 

so I still agree my code is building a second bootloader in to my project.

 

 

So now, I'm down to trying to understand what clawson is explaining.

 

It's an AVR program with two functions in it. One is main() which will be built, along with the interrupt vectors and other CRT stuff down near location 0. Then there is one function (foo()) which is put into a memory section called .bootloader.

Great I follow this but I only have one application main(); yet two are being compiled (text + bootloader)? I do not have any attributes in my code that do that, so why is /bootlaoder even showing up?

The function itself will only be about 8 bytes but when I build I tell the linker to base .bootloader up at a bootloader like address (0x7F00 in this case).

This is very helpful,  I certainly do not do this. I also do not compile my project,  As5 does, and I only use a MAKE file. The Make file knows not of this bootloader.

 

Finally I extract a complete program consisting of .text and .bootloader into a binary file. That file on disk is 32K ! In fact:

I also do not do this.  It is not my intention to do any of that, I have a bootlaoder, I just want to compile the main (.text) and that is all. Where is this .bootloader compiler variable/directive/memory/app  coming from? The best I can tell is it would come from that attribute example you shows me. I search my entire project, in files for bootloader and it is not there. 

 


 

 

 

Last Edited: Sun. Dec 18, 2016 - 01:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So coming back to this a bit with what I feel learned info.

 

Looking at my OP

 

 Size before:
        AVR Memory Usage
        ----------------
        Device: atmega328p
        Program:   28704 bytes (87.6% Full)
        (.text + .data + .bootloader)
        Data:       1227 bytes (59.9% Full)
        (.data + .bss + .noinit)
        Size after:
        AVR Memory Usage
        ----------------
        Device: atmega328p
        Program:   28704 bytes (87.6% Full)
        (.text + .data + .bootloader)
        Data:       1227 bytes (59.9% Full)
        (.data + .bss + .noinit)
        -------- end --------      

 

 

I see this in my make file

COFFCONVERT = $(OBJCOPY) --debugging
COFFCONVERT += --change-section-address .data-0x800000
COFFCONVERT += --change-section-address .bss-0x800000
COFFCONVERT += --change-section-address .noinit-0x800000
COFFCONVERT += --change-section-address .eeprom-0x810000

 

Still completely unclear what this (.text + .data + .bootloader) is coming from though i see the  (.data + .bss + .noinit) in the makefile. but, nnder a the debug: area that is never called.

 

This is the makefile as I have it, guessing its a huge mess or overkill.

 

MCU = atmega328p
F_CPU = 12000000
DEBUG_LEVEL=0
FORMAT = ihex
TARGET = main
OBJDIR =  .
SOURCEDIR = ../BASE_2.0/
# List C source files here. (C dependencies are automatically generated.)
SRC =  /usbdrv/usbdrv.c main.c $(SOURCEDIR)gamepad.c $(SOURCEDIR)gcn64_protocol.c $(SOURCEDIR)i2c.c $(SOURCEDIR)gc.c $(SOURCEDIR)db9.c $(SOURCEDIR)snes.c $(SOURCEDIR)saturn.c $(SOURCEDIR)twelve.c $(SOURCEDIR)jaguar.c $(SOURCEDIR)intellivision.c  $(SOURCEDIR)wii.c $(SOURCEDIR)psx.c $(SOURCEDIR)dreamCast.c $(SOURCEDIR)psx.c $(SOURCEDIR)n64.c $(SOURCEDIR)wii.c $(SOURCEDIR)atmark.c $(SOURCEDIR)gameport.c
# List C++ source files here. (C dependencies are automatically generated.)
CPPSRC =
# List Assembler source files here.
ASRC = /usbdrv/usbdrvasm.S $(SOURCEDIR)dcRead.S
# Optimization level, can be [0, 1, 2, 3, s].
#     0 = turn off optimization. s = optimize for size.
#     (Note: 3 is not always the best optimization level. See avr-libc FAQ.)
OPT = s
#s %80.07
#1 %86.9
#2 %85.5
#3 %110.4

# Debugging format.
#     Native formats for AVR-GCC's -g are dwarf-2 [default] or stabs.
#     AVR Studio 4.10 requires dwarf-2.
#     AVR [Extended] COFF format requires stabs, plus an avr-objcopy run.
DEBUG = dwarf-2

# List any extra directories to look for include files here.
#     Each directory must be seperated by a space.
#     Use forward slashes for directory separators.
#     For a directory that has spaces, enclose it in quotes.
EXTRAINCDIRS = usbdrv

# Compiler flag to set the C Standard level.
#     c89   = "ANSI" C
#     gnu89 = c89 plus GCC extensions
#     c99   = ISO C99 standard (not yet fully implemented)
#     gnu99 = c99 plus GCC extensions
CSTANDARD = -std=gnu99

# Place -D or -U options here for C sources
CDEFS = -DF_CPU=$(F_CPU)L
#-DDEBUG_LEVEL=$(DEBUG_LEVEL)


# Place -D or -U options here for ASM sources
ADEFS = -DF_CPU=$(F_CPU)

# Place -D or -U options here for C++ sources
CPPDEFS = -DF_CPU=$(F_CPU)UL
#CPPDEFS += -D__STDC_LIMIT_MACROS
#CPPDEFS += -D__STDC_CONSTANT_MACROS

#---------------- Compiler Options C ----------------
#  -g*:          generate debugging information
#  -O*:          optimization level
#  -f...:        tuning, see GCC manual and avr-libc documentation
#  -Wall...:     warning level
#  -Wa,...:      tell GCC to pass this to the assembler.
#    -adhlns...: create assembler listing
#CFLAGS = -g$(DEBUG)
CFLAGS += $(CDEFS)
CFLAGS += -O$(OPT)
CFLAGS += -Wall

#force smaller size!
CFLAGS += -fno-inline-small-functions
CFLAGS += -ffunction-sections
CFLAGS += --save-temps
#LDFLAGS += -Wl,--relax
#LDFLAGS += -Wl,--gc-sections
# causes issues ---    CFLAGS += -fwhole-program --combine

CFLAGS += -Wstrict-prototypes
#CFLAGS += -mshort-calls
#CFLAGS += -fno-unit-at-a-time
#CFLAGS += -Wundef
#CFLAGS += -Wunreachable-code
#CFLAGS += -Wsign-compare
CFLAGS += -Wa,-adhlns=$(<:%.c=$(OBJDIR)/%.lst)
CFLAGS += $(patsubst %,-I%,$(EXTRAINCDIRS))
CFLAGS += $(CSTANDARD)


#---------------- Assembler Options ----------------
#  -Wa,...:   tell GCC to pass this to the assembler.
#  -adhlns:   create listing
#  -gstabs:   have the assembler create line number information; note that
#             for use in COFF files, additional information about filenames
#             and function names needs to be present in the assembler source
#             files -- see avr-libc docs [FIXME: not yet described there]
#  -listing-cont-lines: Sets the maximum number of continuation lines of hex
#       dump that will be displayed for a given single line of source input.
ASFLAGS = $(ADEFS) -Wa,-adhlns=$(<:%.S=$(OBJDIR)/%.lst),-gstabs,--listing-cont-lines=100

#---------------- Library Options ----------------
# Minimalistic printf version
PRINTF_LIB_MIN = -Wl,-u,vfprintf -lprintf_min

# Floating point printf version (requires MATH_LIB = -lm below)
PRINTF_LIB_FLOAT = -Wl,-u,vfprintf -lprintf_flt

# If this is left blank, then it will use the Standard printf version.
PRINTF_LIB =
#PRINTF_LIB = $(PRINTF_LIB_MIN)
#PRINTF_LIB = $(PRINTF_LIB_FLOAT)

# Minimalistic scanf version
SCANF_LIB_MIN = -Wl,-u,vfscanf -lscanf_min

# Floating point + %[ scanf version (requires MATH_LIB = -lm below)
SCANF_LIB_FLOAT = -Wl,-u,vfscanf -lscanf_flt

# If this is left blank, then it will use the Standard scanf version.
SCANF_LIB =
#SCANF_LIB = $(SCANF_LIB_MIN)
#SCANF_LIB = $(SCANF_LIB_FLOAT)


MATH_LIB = -lm


# List any extra directories to look for libraries here.
#     Each directory must be seperated by a space.
#     Use forward slashes for directory separators.
#     For a directory that has spaces, enclose it in quotes.
EXTRALIBDIRS =

#---------------- External Memory Options ----------------

# 64 KB of external RAM, starting after internal RAM (ATmega128!),
# used for variables (.data/.bss) and heap (malloc()).
#EXTMEMOPTS = -Wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff

# 64 KB of external RAM, starting after internal RAM (ATmega128!),
# only used for heap (malloc()).
#EXTMEMOPTS = -Wl,--section-start,.data=0x801100,--defsym=__heap_end=0x80ffff

EXTMEMOPTS =

#---------------- Linker Options ----------------
#  -Wl,...:     tell GCC to pass this to linker.
#    -Map:      create map file
#    --cref:    add cross reference to  map file
LDFLAGS = -Wl,-Map=$(TARGET).map,--cref
LDFLAGS += $(EXTMEMOPTS)
LDFLAGS += $(patsubst %,-L%,$(EXTRALIBDIRS))
LDFLAGS += $(PRINTF_LIB) $(SCANF_LIB) $(MATH_LIB)
#LDFLAGS += -T linker_script.x


#---------------- Programming Options (avrdude) ----------------

# Programming hardware
# Type: avrdude -c ?
# to get a full listing.
#
AVRDUDE_PROGRAMMER = stk500

# com1 = serial port. Use lpt1 to connect to parallel port.
AVRDUDE_PORT = usb

AVRDUDE_WRITE_FLASH = -Uflash:w:$(TARGET).hex -B 1.0

AVRDUDE_FLAGS = -p $(MCU) -P $(AVRDUDE_PORT) -c $(AVRDUDE_PROGRAMMER)
AVRDUDE_FLAGS += $(AVRDUDE_NO_VERIFY)
AVRDUDE_FLAGS += $(AVRDUDE_VERBOSE)
AVRDUDE_FLAGS += $(AVRDUDE_ERASE_COUNTER)


# Define programs and commands.
SHELL = sh
CC = avr-gcc
OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump
SIZE = avr-size
AR = avr-ar rcs
NM = avr-nm
AVRDUDE = avrdude
REMOVE = rm -f
REMOVEDIR = rm -rf
COPY = cp
WINSHELL = cmd


# Define Messages
# English
MSG_ERRORS_NONE = Errors: none
MSG_BEGIN = -------- begin --------
MSG_END = --------  end  --------
MSG_SIZE_BEFORE = Size before:
MSG_SIZE_AFTER = Size after:
MSG_COFF = Converting to AVR COFF:
MSG_EXTENDED_COFF = Converting to AVR Extended COFF:
MSG_FLASH = Creating load file for Flash:
MSG_EEPROM = Creating load file for EEPROM:
MSG_EXTENDED_LISTING = Creating Extended Listing:
MSG_SYMBOL_TABLE = Creating Symbol Table:
MSG_LINKING = Linking:
MSG_COMPILING = Compiling C:
MSG_COMPILING_CPP = Compiling C++:
MSG_ASSEMBLING = Assembling:
MSG_CLEANING = Cleaning project:
MSG_CREATING_LIBRARY = Creating library:

# Define all object files.
OBJ = $(SRC:%.c=$(OBJDIR)/%.o) $(CPPSRC:%.cpp=$(OBJDIR)/%.o) $(ASRC:%.S=$(OBJDIR)/%.o)

# Define all listing files.
LST = $(SRC:%.c=$(OBJDIR)/%.lst) $(CPPSRC:%.cpp=$(OBJDIR)/%.lst) $(ASRC:%.S=$(OBJDIR)/%.lst)

# Compiler flags to generate dependency files.
GENDEPFLAGS = -MMD -MP -MF .dep/$(@F).d

# Combine all necessary flags and optional flags.
# Add target processor to flags.
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)


# Default target.
all: begin gccversion sizebefore build sizeafter end

# Change the build target to build a HEX file or a library.
build: elf hex eep lss sym
#build: lib


elf: $(TARGET).elf
hex: $(TARGET).hex
eep: $(TARGET).eep
lss: $(TARGET).lss
sym: $(TARGET).sym
LIBNAME=lib$(TARGET).a
lib: $(LIBNAME)


# Eye candy.
# AVR Studio 3.x does not check make's exit code but relies on
# the following magic strings to be generated by the compile job.
begin:
    @echo
    @echo $(MSG_BEGIN)
    
end:
    @echo $(MSG_END)
    @echo


# Display size of file.
HEXSIZE = $(SIZE) --target=$(FORMAT) $(TARGET).hex
ELFSIZE = $(SIZE) --mcu=$(MCU) --format=avr $(TARGET).elf

sizebefore:

    @if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_BEFORE); $(ELFSIZE); \
    2>/dev/null; echo; fi

sizeafter:
    @if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_AFTER); $(ELFSIZE); \
    2>/dev/null; echo; fi


# Display compiler version information.
gccversion :
    @$(CC) --version


# Program the device.  
program: $(TARGET).hex $(TARGET).eep
    $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH) $(AVRDUDE_WRITE_EEPROM)


# Generate avr-gdb config/init file which does the following:
#     define the reset signal, load the target file, connect to target, and set
#     a breakpoint at main().
gdb-config:
    @$(REMOVE) $(GDBINIT_FILE)
    @echo define reset >> $(GDBINIT_FILE)
    @echo SIGNAL SIGHUP >> $(GDBINIT_FILE)
    @echo end >> $(GDBINIT_FILE)
    @echo file $(TARGET).elf >> $(GDBINIT_FILE)
    @echo target remote $(DEBUG_HOST):$(DEBUG_PORT)  >> $(GDBINIT_FILE)
ifeq ($(DEBUG_BACKEND),simulavr)
    @echo load  >> $(GDBINIT_FILE)
endif
    @echo break main >> $(GDBINIT_FILE)


coff: $(TARGET).elf
    @echo
    @echo $(MSG_COFF) $(TARGET).cof
    $(COFFCONVERT) -O coff-avr $< $(TARGET).cof


extcoff: $(TARGET).elf
    @echo
    @echo $(MSG_EXTENDED_COFF) $(TARGET).cof
    $(COFFCONVERT) -O coff-ext-avr $< $(TARGET).cof


# Create final output files (.hex, .eep) from ELF output file.
%.hex: %.elf
    @echo
    @echo $(MSG_FLASH) $@
    $(OBJCOPY) -O $(FORMAT) -R .eeprom -R .fuse -R .lock $< $@

%.eep: %.elf
    @echo
    @echo $(MSG_EEPROM) $@
    -$(OBJCOPY) -j .eeprom --set-section-flags=.eeprom="alloc,load" \
    --change-section-lma .eeprom=0 --no-change-warnings -O $(FORMAT) $< $@ || exit 0

# Create extended listing file from ELF output file.
%.lss: %.elf
    @echo
    @echo $(MSG_EXTENDED_LISTING) $@
    $(OBJDUMP) -h -S -z $< > $@

# Create a symbol table from ELF output file.
%.sym: %.elf
    @echo
    @echo $(MSG_SYMBOL_TABLE) $@
    $(NM) -n $< > $@


# Create library from object files.
.SECONDARY : $(TARGET).a
.PRECIOUS : $(OBJ)
%.a: $(OBJ)
    @echo
    @echo $(MSG_CREATING_LIBRARY) $@
    $(AR) $@ $(OBJ)


# Link: create ELF output file from object files.
.SECONDARY : $(TARGET).elf
.PRECIOUS : $(OBJ)
%.elf: $(OBJ)
    @echo
    @echo $(MSG_LINKING) $@
    $(CC) $(ALL_CFLAGS) $^ --output $@ $(LDFLAGS)


# Compile: create object files from C source files.
$(OBJDIR)/%.o : %.c
    @echo

    @echo $(MSG_COMPILING) $<
                
    $(CC) -c $(ALL_CFLAGS) $< -o $@


# Compile: create object files from C++ source files.
$(OBJDIR)/%.o : %.cpp
    @echo
    @echo $(MSG_COMPILING_CPP) $<
    $(CC) -c $(ALL_CPPFLAGS) $< -o $@


Compile: create assembler files from C source files.
%.s : %.c
    $(CC) -S $(ALL_CFLAGS) $< -o $@


# Compile: create assembler files from C++ source files.
%.s : %.cpp
    $(CC) -S $(ALL_CPPFLAGS) $< -o $@


# Assemble: create object files from assembler source files.
$(OBJDIR)/%.o : %.S
    @echo
    @echo $(MSG_ASSEMBLING) $<
    $(CC) -c $(ALL_ASFLAGS) $< -o $@


# Create preprocessed source for use in sending a bug report.
%.i : %.c
    $(CC) -E -mmcu=$(MCU) -I. $(CFLAGS) $< -o $@


# Target: clean project.
clean: begin clean_list end

clean_list :
    @echo
    @echo $(MSG_CLEANING)
    $(REMOVE) $(TARGET).hex
    $(REMOVE) $(TARGET).eep
    $(REMOVE) $(TARGET).cof
    $(REMOVE) $(TARGET).elf
    $(REMOVE) $(TARGET).map
    $(REMOVE) $(TARGET).sym
    $(REMOVE) $(TARGET).lss
    $(REMOVE) $(SRC:%.c=$(OBJDIR)/%.o)
    $(REMOVE) $(SRC:%.c=$(OBJDIR)/%.lst)
    $(REMOVE) $(SRC:.c=.s)
    $(REMOVE) $(SRC:.c=.d)
    $(REMOVE) $(SRC:.c=.i)
    $(REMOVEDIR) .dep


# Create object files directory
$(shell mkdir $(OBJDIR) 2>/dev/null)


# Include the dependency files.
-include $(shell mkdir .dep 2>/dev/null) $(wildcard .dep/*)


# Listing of phony targets.
.PHONY : all begin finish end sizebefore sizeafter gccversion \
build elf hex eep lss sym coff extcoff \
clean clean_list program debug gdb-config



 

 

Last Edited: Wed. Apr 26, 2017 - 12:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:

I see this in my make file

COFFCONVERT = $(OBJCOPY) --debugging
COFFCONVERT += --change-section-address .data-0x800000
COFFCONVERT += --change-section-address .bss-0x800000
COFFCONVERT += --change-section-address .noinit-0x800000
COFFCONVERT += --change-section-address .eeprom-0x810000

S_K_U_N_X wrote:
but, nnder a the debug: area that is never called.

S_K_U_N_X wrote:
This is the makefile as I have it

Are you talking about two different makefiles? Neither do I see the COFFCONVERT lines in there, nor a debug target.

Anyway!

 

I read the other posts and Cliff (clawson) was misleading you. No need to worry about the .bootloader in "(.text + .data + .bootloader)", it is always there. The program avr-size lists the sections that are added up if existent. That doesn't mean that .bootloader is actually existent.

 

S_K_U_N_X wrote:
5.8 + 87 is not 100
Not necessarily. Whether 87% application and 5.8% bootloader fit into the memory depends on where the bootloader is actually located.

S_K_U_N_X wrote:
The bootloader says it failed at 0x7080.
This is a hint that you may have selected the biggest possible bootloader section size for an Mega328.

Stefan Ernst

Last Edited: Wed. Apr 26, 2017 - 08:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sternst wrote:
was misleading you
Apologies - clearly having a bad day that particular day so try to read this thread ignoring any posts from me! blush

 

.bootloader is a complete red herring. The point is that a Bootloader Program is simply a "normal" program that has its .text section relocated. That is what you are achieving here when you use:

-Wl,-section-start=.text=0x7800

 

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

Ok Cliff LOL, take a break.

 

sternst, yes this is two projects.

 

looks like the makefile I attached was the stripped down version where I remove the debug call. So those COFFCONVERT 's are missing, sorry about that.

 

I'm still putting together how all of this works so I do apologize in advance here. I was scratching my head trying to find this reported boot loader. I knew this info is above but sometimes it's annoying to read thru it all, but.  In a very simple sense I build a bootloader (I didn't write it) for a 328 chip. The size of that build and make file is on line #11 and #14. This then is used to load my main code. That reports as seen on post #15 and is also built for a 328.

 

So how can I determine the exact limit of the size. I'm just not certain how to calculate that. The number are all here. The complete source for the bootloader is available on line as pointed out in post #11. Is 7800 the lowest for 328?

 

 

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

S_K_U_N_X wrote:
The number are all here.
Nope. One information is missing, the size of the bootloader area selected by the fuses. It is only my guess based on the error message that it may be 4k.

S_K_U_N_X wrote:
Is 7800 the lowest for 328?
You don't need the lowest, you need the one fitting your bootloader. And that is indeed 0x7800. ;-)

Stefan Ernst

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

Ah, that maybe it. The fuses were for a 168 originally and I moved to a 328. I'll report back with fuses.

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

Bootloader

Fuses used FD:ex 5A:hi DF:lo (bit is set for bootloader address)

make file says 7800 for bootloader address.

chip mega 328

 

 

If I need to add more info let me know.

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

Fuse values look OK and the BOOTSZ setting does pick 3C00/7800 entry.

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

ok but 

So how can I determine the exact limit of the size. I'm just not certain how to calculate that. The number are all here. The complete source for the bootloader is available on line as pointed out in post #11. Is 7800 the lowest for 328?

 

I'm still not certain how this all adds up. With the data above I should be able to say max program size is x = b + p.

x= chip size (32k) 

b=botlaoder ( I think I can get this from post #11 with the new provided details)

p=program size (what is the size this needs to be under)

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

b = 0x8000 - 0x7800 = 0x800 = 2K

p = 32K - b = 30K

 

As soon as you set BOOTSZ[1:0] to the 0x7800 position all these numbers become set in stone.

 

Your other options are:

 

BOOTSZ1 BOOTSZ0  BLS(word) BLS(byte)  b   p

   0       0      0x3800    0x7000   4K  28K

   0       1      0x3C00    0x7800   2K  30K   <<<<<<<<< using this now

   1       0      0x3E00    0x7C00   1K  31K

   1       1      0x3F00    0x7E00  0.5K 31.5K

 

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

ok but my bootloader is 2k, so I must use at lease 01. And that is how its being used at the moment. 

 

so I see it this way

 

x= chip size (32k) 

b=botlaoder 2k

p=application must be less then or equal to 30k but its building at 28704 (see first post) Unless I missed something?

 

so I still have room but it says full when load with the bootloader. 

 

device size -00032768

data (28674) exceeds flash size!

flashing 28800 (0x7080) bytes  start at 0

 

 

 

Last Edited: Wed. May 3, 2017 - 01:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
but it says full when load
What is saying "full"?

 

Either the PC tool that produces this message is in error or, more likely, the PC tool asks the AVR bootloader "what is the maximum size you can accept" and the answer that gives is in error.

 

Is the bootloader AVR109 protocol or something? I'm pretty sure that protocol includes a command for the bootloader to report the maximum size it thinks it can accept. Either the bootloader has 4K or 28K "burnt in" when it is supposed to be 2K or 30K (depending on which way round it reports the boundary).

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

Ok then I think we are getting close to the issue. So I use this. 

http://vusb.wikidot.com/project:...

maybe the code in this tool is set for a 4k assumption? - ill try to dig up the source. 

 

Last Edited: Wed. May 3, 2017 - 01:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK so I went back to post #1 and followed the link to the bootloader code. It has both PC and AVR sides of the code. In the PC (commandline) code one sees:

        if(endAddr > deviceSize - 2048){
            fprintf(stderr, "Data (%d bytes) exceeds remaining flash size!\n", endAddr);
            err = -1;
            goto errorOccurred;
        }

So that's where your:

data (28674) exceeds flash size!

is coming from. The hard coded 2048 there would seem to suggest that it is assumed that the bootloader is 2K and the code is therefore 32K (deviceSize) - 2K = 30K.

 

So it's a bit of mystery why this would report 28674 (28K) as failing the test? Have you modified this PC code in some way?

 

On the other hand maybe deviceSize is in error? Immediately before that error is displayed it does:

        deviceSize = getUsbInt(buffer.info.flashSize, 4);
        printf("Page size   = %d (0x%x)\n", pageSize, pageSize);
        printf("Device size = %d (0x%x); %d bytes remaining\n", deviceSize, deviceSize, deviceSize - 2048);

So what do you actually see output for "Page Size = " and "Device Size = " ?

 

The deviceSize itself appears to be reported back from the AVR and collected with:

        deviceSize = getUsbInt(buffer.info.flashSize, 4);

so maybe the fault is in the AVR code itself - perhaps it is not reporting 32K here ?

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

I was not very clear on the code when I started this but I now know that I have two flashing apps. 

bootloadflash and FW updater.

The source you see is FW updater. The code I'm using is bootloadflash. It is possible bootloadflash does not have that 2k limit but the source is tied up ATM. I can try to build from source and try the FW updater and see it that flashes. 

 

I'll also get the "Page Size = " and "Device Size = " output and report back. Thx for the help so far I'm getting closer here. 

Last Edited: Wed. May 3, 2017 - 02:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This has me intrigued. So the page/device size seem to come as a result of:

    if(endAddr > startAddr){    // we need to upload data
        if((err = usbGetReport(dev, USB_HID_REPORT_TYPE_FEATURE, 1, buffer.bytes, &len)) != 0){
            fprintf(stderr, "Error reading page size: %s\n", usbErrorMessage(err));
            goto errorOccurred;
        }

which then made me wonder how the AVR side would receive/handle the USB_HID_REPORT_TYPE_FEATURE. So on the PC side I see:

int usbGetReport(usbDevice_t *device, int reportType, int reportNumber, char *buffer, int *len)
{
HANDLE  handle = (HANDLE)device;
BOOLEAN rval = 0;
DWORD   bytesRead;

    switch(reportType){
    case USB_HID_REPORT_TYPE_INPUT:
        buffer[0] = reportNumber;
        rval = ReadFile(handle, buffer, *len, &bytesRead, NULL);
        if(rval)
            *len = bytesRead;
        break;
    case USB_HID_REPORT_TYPE_OUTPUT:
        break;
    case USB_HID_REPORT_TYPE_FEATURE:
        buffer[0] = reportNumber;
        rval = HidD_GetFeature(handle, buffer, *len);
        break;
    }
    return rval == 0 ? USB_ERROR_IO : 0;
}

The final case there is handling this call for data. But the function it calls only gets mentioned in .h files. I don't see an implementation so it's presumably in a linked library and a "standard" call:

BOOLEAN __stdcall   HidD_GetFeature(IN HANDLE device, OUT void *reportBuffer, IN ULONG bufferLen);

so the trail goes kind of cold at this stage except that Microsoft ARE good at documenting their own code...

 

https://msdn.microsoft.com/en-us/library/windows/hardware/ff538910(v=vs.85).aspx

 

What can be seen is that:

        buffer[0] = reportNumber;

is setting the byte to 1. So this is making a HID request for "report 1".

 

I guess it's then just a question of understanding how this is handled on the V-USB side of things. So if I just grep for "report" in the USBdrv code I find:

C:\bootloadHID.2012-12-08\firmware\usbdrv>grep -i report *
Changelog.txt:    always zero sized. This fixes a bug where the host reports an error after
Changelog.txt:  - Fixed bug in libs-host/hiddata.c function usbhidGetReport(): length
usbconfig-prototype.h:/* #define USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH    42 */
usbconfig-prototype.h:/* Define this to the length of the HID report descriptor, if you implement
usbconfig-prototype.h: * "usbHidReportDescriptor" to your code which contains the report descriptor.
usbconfig-prototype.h: *   char usbDescriptorHidReport[];
usbconfig-prototype.h: *   USB_CFG_DESCR_PROPS_HID_REPORT
usbconfig-prototype.h:#define USB_CFG_DESCR_PROPS_HID_REPORT              0
usbdrv.c:#if USB_CFG_DESCR_PROPS_HID_REPORT != 0 && USB_CFG_DESCR_PROPS_HID == 0
usbdrv.c:    0x01,       /* number of HID Report (or other HID class) Descriptor infos to follow */
usbdrv.c:    0x22,       /* descriptor type: report */
usbdrv.c:    USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH, 0,  /* total length of report descriptor */
usbdrv.c:#if USB_CFG_DESCR_PROPS_HID_REPORT  /* only support HID descriptors if enabled */
usbdrv.c:    SWITCH_CASE(USBDESCR_HID_REPORT)/* 0x22 */
usbdrv.c:        GET_DESCRIPTOR(USB_CFG_DESCR_PROPS_HID_REPORT, usbDescriptorHidReport)
usbdrv.c: * code and report errors back to the host. Since the ACK was already sent,
usbdrv.h:#if USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH    /* simplified interface for backward compatibility */
usbdrv.h:#define usbHidReportDescriptor  usbDescriptorHidReport
usbdrv.h:/* should be declared as: PROGMEM char usbHidReportDescriptor[]; */
usbdrv.h:/* If you implement an HID device, you need to provide a report descriptor.
usbdrv.h: * The HID report descriptor syntax is a bit complex. If you understand how
usbdrv.h: * report descriptors are constructed, we recommend that you use the HID
usbdrv.h:#endif  /* USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH */
usbdrv.h:#if !(USB_CFG_DESCR_PROPS_HID_REPORT)
usbdrv.h:#   undef USB_CFG_DESCR_PROPS_HID_REPORT
usbdrv.h:#   if USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH /* do some backward compatibility tricks */
usbdrv.h:#       define USB_CFG_DESCR_PROPS_HID_REPORT       USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH
usbdrv.h:#       define USB_CFG_DESCR_PROPS_HID_REPORT       0
usbdrv.h:#if !(USB_CFG_DESCR_PROPS_HID_REPORT & USB_PROP_IS_RAM)
usbdrv.h:char usbDescriptorHidReport[];
usbdrv.h:#   if USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH
usbdrv.h:#define USBDESCR_HID_REPORT     0x22
usbdrv.h:#define USBRQ_HID_GET_REPORT    0x01
usbdrv.h:#define USBRQ_HID_SET_REPORT    0x09

Of all that the most likely candidate looks like usbdrv.c but try as I might I cannot spot anything there that is saying "28K"

Last Edited: Wed. May 3, 2017 - 02:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Turns out the source forbootloadflash is gone lost forever according to the author. The main issue with FW updater is really hard to compile so I may not be able to make it work as things have changed so much over the years. 

 

So you are pretty sure the code is using something from the v-usb protect to determine the size? That I may be able to get answered. I'll contact Christian. But, from what I know this is a HID feature that sends data to the device. The feature report is how the usb sends the data. I think that like may just be a check for end of file or maybe an initial check for size 0. 

 

 

Last Edited: Wed. May 3, 2017 - 02:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What it appears is that the PC software "asks" the AVR code for a "report" and that report comes back with both SPM page size and also actual device size.

 

I'll bet your AVR code is saying it's a 16K mega168 or something like that. The PC app would then not be able to send more than 14K as it gives the error at "reportedSize - 2K". Certainly 28K would be too much.

 

I guess it's just a case of working out where in the AVR side of things it actually reports "16K" or whatever it is.

 

Now I just had a thought. It appears to report both SPM_PAGESIZE and the device size. So if one looked for references to the SPM pagesize in the AVR code one might also find the nearby code that might be saying something like "16K".

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

And that was the lead I needed. The main.c for the AVR code has:

static uchar    replyBuffer[7] = {
        1,                              /* report ID */
        SPM_PAGESIZE & 0xff,
        SPM_PAGESIZE >> 8,
        ((long)FLASHEND + 1) & 0xff,
        (((long)FLASHEND + 1) >> 8) & 0xff,
        (((long)FLASHEND + 1) >> 16) & 0xff,
        (((long)FLASHEND + 1) >> 24) & 0xff
    };

    if(rq->bRequest == USBRQ_HID_SET_REPORT){
        if(rq->wValue.bytes[0] == 2){
            offset = 0;
            return USB_NO_MSG;
        }

This is the return for that call to

HidD_GetFeature()

in the PC code. So clearly it sends the SPM page size first:

        SPM_PAGESIZE & 0xff,
        SPM_PAGESIZE >> 8,

and then the size of the device as:

        ((long)FLASHEND + 1) & 0xff,
        (((long)FLASHEND + 1) >> 8) & 0xff,
        (((long)FLASHEND + 1) >> 16) & 0xff,
        (((long)FLASHEND + 1) >> 24) & 0xff

It's actually quite tricky to see how that could have been built with the "wrong answer" because "FLASHEND" comes via <avr/io.h> and for a 328 is:

C:\SysGCC\avr\avr\include\avr>grep FLASH iom328*
#define FLASHEND     0x7FFF

So FLASHEND+1 is 0x8000 and that is effectively the value being conveyed back from the AVR to the PC. We know that in the PC code it then has a fixed subtraction of 2048 (2K) so it should get 32K-2K = 30K as the boundary.

 

HOWEVER if you are saying that the PC app you use is not built from the visible source (that definitely has "- 2048") but is a pre-built EXE then I can well imagine a scenario where, before some optimisation, this bootloader maybe spilled slightly over 2K in size and it would have necessitated a 4K BOOTSZ being used and in that case maybe the previous PC software contained a fixed "- 4096" ? So for a 32K device it might reject anything over 28K. Which is what you are seeing.

 

Is there some reason you cannot simply rebuild the PC application code then? Copies of Visual Studio ("Express") are free to access and should allow you to build the code I think. Actually the Makefile they supply suggests the use of MinGW which is the GCC compiler for Windows.

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

avr as in my projects firmware I make with avr studio?

Last Edited: Wed. May 3, 2017 - 03:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes.

 

The acrhive contains two components. firmware and firmware/usbdrv together are the AVR code of the bootloader. The commandline directory contains the source of the PC application (and a prebuilt bootloadHID.exe)

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

 can try to use the bootloader of the source you looked at and see if it works. 

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

clawson wrote:
I guess it's just a case of working out where in the AVR side of things it actually reports "16K" or whatever it is.
But ...

S_K_U_N_X wrote:
device size -00032768

data (28674) exceeds flash size!

flashing 28800 (0x7080) bytes start at 0

What puzzles me is the '-' there. Would be interesting to know wether the OP is able to upload anything at all. If it is really a minus then even the upload of a very small application should fail. And then the cause is very likely an unwanted sign extension somewhere.

Stefan Ernst

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

I think its a dash. Anything lower then 85% or so flashes fine. 

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

Stefan. If the source is to be believed the PC app does this:

printf("Device size = %d (0x%x); %d bytes remaining\n", deviceSize, deviceSize, deviceSize - 2048);

so I know it's a pedantic detail but that is a capital 'D' and the "Device size" is followed by " = " so either this is not the active source or the

device size -00032768

is possibly a retype job that went a bit wrong. Perhaps "-" was supposed to be typed as " = " ??

 

Actually, assuming the tool being used is the prebuilt EXE in the archive then...

C:\bootloadHID.2012-12-08\commandline>strings bootloadHID.exe | grep size
Error reading page size: %s
Page size   = %d (0x%x)
Device size = %d (0x%x); %d bytes remaining
Data (%d bytes) exceeds remaining flash size!

Also:

flashing 28800 (0x7080) bytes start at 0

seems unlikely when:

C:\bootloadHID.2012-12-08\commandline>strings bootloadHID.exe | grep start
Uploading %d (0x%x) bytes starting at %d (0x%x)

So I think what he really saw was:

Device size = 32768 (0x8000); ?????? bytes remaining
Data (28674 bytes) exceeds remaining flash size!
Uploading 28800 (0x7080) bytes starting at 0 (0x0)

The ????? may be the key thing here. The question is whether it is 32768 - 2048 0r 32768 - 4096. My money on the latter.

 

(actually, just thought, I can disassemble this prebuilt EXE and see whether it is 2048 or 4096 that is being subtracted).

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

clawson wrote:
Stefan. If the source is to be believed the PC app does this:

printf("Device size = %d (0x%x); %d bytes remaining\n", deviceSize, deviceSize, deviceSize - 2048);

so I know it's a pedantic detail but that is a capital 'D' and the "Device size" is followed by " = " so either this is not the active source or the

device size -00032768

is possibly a retype job that went a bit wrong. Perhaps "-" was supposed to be typed as " = " ??

Not only typing 'd' instead of 'D' and '-' instead of '=', but also adding three '0'???

Doesn't your code come from the command line app while he is using the GUI app?

Perhaps the GUI app uses a slightly different output.

Anyway, the OP can easily clarify that. ;-)

Stefan Ernst

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

OK so disassembler says:

 

 

The printf() it's about to call there is:

 

printf("Device size = %d (0x%x); %d bytes remaining\n", deviceSize, deviceSize, deviceSize - 2048);

and the FFFFF800 in the LEA is a -2048. So ???? is going to be 30720 in fact.

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

Cliff, I think you are not looking at the sources of the PC app he is actually using. In #27 he gave a link and there you can read:

HIDBootFlash is a GUI and command line tool used to download firmware to a controller with BootloadHID or AVRUSBBoot equivalent boot loader. It is quite similar to the FW Uploader (www.bootloader.nm.ru/) but not taking advantage of the Fischl BootloadHID.exe.

Stefan Ernst

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

That link seems to take me to some kind of Russian "Instagram"! No thanks.

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

clawson wrote:
That link seems to take me to some kind of Russian "Instagram"! No thanks.
The link is not the interesting part, but the "not taking advantage of the Fischl BootloadHID.exe".

Stefan Ernst

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

There is no way to get the source to the app I'm using.  If you want to disassemble it use this exe http://vusb.wikidot.com/project:...

 

Going to try using the bootloadhid now (source you are looking at). and see if I get the error.

 

 

good flash

Page size   = 128 (0x80)
Device size = 32768 (0x8000); 30720 bytes remaining
Uploading 28672 (0x7000) bytes starting at 0 (0x0)
0x06f80 ... 0x07000

 

 

bad flash

Page size   = 128 (0x80)
Device size = 32768 (0x8000); 30720 bytes remaining
Uploading 28800 (0x7080) bytes starting at 0 (0x0)
0x07000 ... 0x07080Error uploading data block: Communication error with device

 

Last Edited: Wed. May 3, 2017 - 10:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Previously you said you were getting an error such as:

data (28674) exceeds flash size!

Neither your good nor your bad case has any such message about the size exceeding some limit?!?

 

The error is about communications.

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

clawson wrote:
Previously you said you were getting an error such as:
He is using a different PC tool now (the one you inspected).

Stefan Ernst

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

Right as sternst has been saying as I tried to illustrate. 

 

initial issue program 1) gave result A

You were looking at the source to program 2)

So I used program 2) and got result B

 

Either way I get the same "kinda" of error on both programs, I just figured it was best to use the program you are seeing the source for. Trying to make things easier here, though looks like I just made them more confusing.

 

From my latest tests the good flash is with a hex size of under %85 full from AVR studio. The bad I added a few lines of code to make it greater then 87 in AVR to show that it fails. The "Communication error with device" is obviously an incorrect error (or just throwing another after the data block error).  It still communicates fine, just fails because of the hex size. I see it flashing just like the flash that succeeded, only it stops with that errors towards the end of the flashing. I think the real error is "Error uploading data block:" The issue here is that is throws a fit when it tries uploading and gets to  28800 (0x7080) 

 

I think program 1 is derived from program 2. I think the program 1 was just a gui version of 2. Though he wrote his own errors for the gui. I may just have to open the damn source compile it and debug from with in. That or set a file size constant limit of 30k. 

 

 

Last Edited: Thu. May 4, 2017 - 01:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure I can follow the problem (-.-)a

Just asking

So the OP needs PC tools for downloading Hex via bootloader? or the bootloader itself?

I'm using improved AVRUSBBoot and my selfmade Windows PC tool GUI

I've tried Fischl BootloadHID with HIDBootFlash too, but I like mine better :)

I don't know why I'm still doing this hobby

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

So the OP needs PC tools for downloading Hex via bootloader? or the bootloader itself?

I need a PC tool that works. Mine seems to be limited to a 4k bootloader and I need it to allow for a  2k.

 

The device I have uses a hid data transfer

https://github.com/obdev/v-usb/t...

 

It sounds like your tool may do the same? Can I try it?

 

Last Edited: Fri. May 5, 2017 - 01:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My GUI tool looks like this

 

 

My bootloader was AVRUSBBoot with some added task.

The bootloader size is about 2K

I'm still working on it for improvement. 

The schematics is USBASP, and the speed jumper is use for bootloader switch.

 

Do you have device with USBASP schematics?

I'll try to compile the bootloader for you so you can try to program it for yourself and test it with the GUI above.

 

ATmega 8 at 12 MHz (USBASP)

https://www.4shared.com/rar/OKW0hYCCei/zip.html

 

I don't know why I'm still doing this hobby

Last Edited: Fri. May 5, 2017 - 02:11 PM

Pages