Pages: 1 2 [3]   Go Down
Author Topic: bug in optiboot bootloader  (Read 3045 times)
0 Members and 1 Guest are viewing this topic.
SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 137
Posts: 6792
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Rapa Nui
Offline Offline
Edison Member
*
Karma: 60
Posts: 2086
Pukao hats cleaning services
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
« Last Edit: August 03, 2013, 08:05:36 am by pito » Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2745
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Offline Offline
Jr. Member
**
Karma: 2
Posts: 99
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 70
Posts: 2745
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Offline Offline
Jr. Member
**
Karma: 2
Posts: 99
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


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.
Logged

Offline Offline
Jr. Member
**
Karma: 2
Posts: 99
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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:
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:
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:
// top snipped off
:1001D000816080838081806880831092C10008954F
:0401E000F894FFCFC1
:1001E400FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1B
:00000001FF
Logged

Offline Offline
Jr. Member
**
Karma: 2
Posts: 99
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


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.
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 137
Posts: 6792
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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...

* test_ff_pages.zip (1.75 KB - downloaded 11 times.)
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 210
Posts: 13039
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


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.
Logged

Pages: 1 2 [3]   Go Up
Jump to: