Go Down

Topic: bug in optiboot bootloader (Read 3402 times) previous topic - next topic

westfw

Huh.  How do you even GET trailing 0xFFs in the .data segment?
I'm always getting .data from the Arduino libraries beyond everything I put in the user area of the sketch.

Libraries?

008001be d _ZL8mystdout
00800200 D trailff_RAM               ;; structure with trailing FFs
00800280 V _ZTV14HardwareSerial      ;; structure from libraries.
00800290 B __bss_start
00800290 D __data_end

pito

#31
Aug 03, 2013, 12:18 pm Last Edit: Aug 03, 2013, 03:05 pm by pito Reason: 1
Quote
the new avrdude only burns and verifies the actual pages with real data in them.
The burn/verify time for optiboot using USBASP is less than 1 second now.

Where we can get that latest avrdude?

Here for example (6.0rc2):

http://www.mikrocontroller.net/topic/296379#3166155

bperrybap


Where we can get that latest avrdude?

You will have to build it yourself.
From the repository:
http://savannah.nongnu.org/svn/?group=avrdude
There are also some tar'ed up source versions available:
http://download.savannah.gnu.org/releases/avrdude/

Just get and build whatever version you want for your OS platform.
note: there are quite a few tools that must be in place to be
able to do native s/w development and for those still using Windows,
it isn't quite as easy to get them in place as those running
linux OS's.

--- bill

g_u_e_s_t


If it is ONLY the block at the very end of the sketch, that's a much less serious problem.  IMO.



this definitely means it will effect fewer people, but also means it will be far more confusing when it does happen.  the partial page trailing FF's seems like an easy fix anyways.  not sure anything can be done on the optiboot side for full pages at the end of a .hex file.

bperrybap



If it is ONLY the block at the very end of the sketch, that's a much less serious problem.  IMO.



this definitely means it will effect fewer people, but also means it will be far more confusing when it does happen.  the partial page trailing FF's seems like an easy fix anyways.  not sure anything can be done on the optiboot side for full pages at the end of a .hex file.


Couldn't you put a dummy section at the end of the linked image to ensure that this never happened?
Yeah, it would require a tweak to the Arduino team controlled code but it's a one time thing.

g_u_e_s_t



Couldn't you put a dummy section at the end of the linked image to ensure that this never happened?
Yeah, it would require a tweak to the Arduino team controlled code but it's a one time thing.


that would probably work.  i am essentially doing that manually with my code by adding a single, non-FF variable after all the FF ones.

g_u_e_s_t


Huh.  How do you even GET trailing 0xFFs in the .data segment?
I'm always getting .data from the Arduino libraries beyond everything I put in the user area of the sketch.

Libraries?

008001be d _ZL8mystdout
00800200 D trailff_RAM               ;; structure with trailing FFs
00800280 V _ZTV14HardwareSerial      ;; structure from libraries.
00800290 B __bss_start
00800290 D __data_end



im not sure i understand the question, but if i do this:

Code: [Select]

int buff[8] = {0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff};

void setup() {}

void loop() {
  for (int i = 0; i < 8; i++) {
    PORTD = buff[i];
  }
}


i get this:

Code: [Select]

sketch_aug03a.cpp.elf:     file format elf32-avr

Contents of section .data:
800100 ffffffff ffffffff ffffffff ffffffff


which is put at the end of the .hex file

Code: [Select]

// top snipped off
:1001D000816080838081806880831092C10008954F
:0401E000F894FFCFC1
:1001E400FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1B
:00000001FF

g_u_e_s_t



Couldn't you put a dummy section at the end of the linked image to ensure that this never happened?
Yeah, it would require a tweak to the Arduino team controlled code but it's a one time thing.


another nice thing about this method, is that people could just update their arduino ide, rather than burning a new bootloader.

westfw

I guess that one of the reasons that this doesn't seem to cause many problems is that if you use any arduino library that has .data, it will show up AFTER the user variables and prevent the problem...

(Since avrdude does blocks with trailing FF bytes in the middle of the sketch, I'm not sure why it has decided that it doesn't need to do things that way at the end of the sketch...)

Here's the sketch...

Coding Badly


For what it's worth, this appears to be the most relevant bug report (Status: Invalid)...
http://savannah.nongnu.org/bugs/?func=detailitem&item_id=30061

@g_u_e_s_t (and anyone else who wants the problem fixed at the root), please add your 2ยข to that report.

Go Up