Modify the Optiboot bootloader to be able to read and write to flash from application

[MCUdude]

This feature is allready included in the MightyCore, and should be able to implement in this core as well. I've already tried adding the additional functionality, but I haven't succeeded. The compiler gave me som strange error about some numbers that needed to be less than 64. Maybe @sunnyque can help? 😃

[sunnyque]

What exactly error description is?

[MCUdude]

Here is the the file I've tried to port (the whole bootloader folder is attached). Here is the output from the make command

make atmega128 AVR_FREQ=16000000L BAUD_RATE=115200 UART=0 LED=B5 LED_START_FLASHES=2 -BIGBOOT

avr-gcc (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
BAUD RATE CHECK: Desired: 115200, Real: 117647, UBRRL = 16, Error=-2.1%
avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -save-temps -mmcu=atmega128 -DF_CPU=16000000L  -DBAUD_RATE=115200 -DLED_START_FLASHES=2    -DLED=B5  -DBIGBOOT -DUART=0   -c -o optiboot.o optiboot.c
optiboot.c:305:2: warning: #warning BAUD_RATE error greater than -2% [-Wcpp]
 #warning BAUD_RATE error greater than -2%
  ^
optiboot.s: Assembler messages:
optiboot.s:27: Error: number must be positive and less than 64
optiboot.s:50: Error: number must be positive and less than 64
make: *** [optiboot.o] Error 1

optiboot_flash.zip

[sunnyque]

Try to compile optiboot with older AVR toolset (WinAVR-20100110)

[MCUdude]

I'm using a mac, so WinAVR won't work. but why shouldn't this work with this toolchain? I've compiled Optiboot for the MightyCore with this toolchain version.

[sunnyque]

Because it compiles without those errors with WinAVR-20100110 :) I've got errors like "number must be positive and less than 64" in past while trying to build optiboot for 1284p, toolset downgrade fixes this for me. I'm thinking there is a problems with compiler optimizations or whatever. I haven't dig it seriously

[MCUdude]

I downgraded to Crosspack-AVR-20100115 (avr-gcc v.4.3.3) and this is the output:

$ make atmega128 AVR_FREQ=16000000L BAUD_RATE=115200 UART=0 LED=B5 LED_START_FLASHES=2 -BIGBOOT
avr-gcc (GCC) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

BAUD RATE CHECK: Desired: 115200, Real: 117647, UBRRL = 16, Error=-2.1%
avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -save-temps -mmcu=atmega128 -DF_CPU=16000000L  -DBAUD_RATE=115200 -DLED_START_FLASHES=2    -DLED=B5  -DBIGBOOT -DUART=0   -c -o optiboot.o optiboot.c
optiboot.c:305:2: warning: #warning BAUD_RATE error greater than -2%
optiboot.s: Assembler messages:
optiboot.s:203: Error: number must be positive and less than 64
optiboot.s:225: Error: number must be positive and less than 64
make: *** [optiboot.o] Error 1

[sunnyque]

Ooops, sorry, I was wrong. It seems I just used make from WinAVR-20100110\utils\bin\ , but it calls avr-gcc 4.8.1 (that ships with arduino sdk, Iam building from src placed at \Arduino\hardware\MightyCore\avr\bootloaders\optiboot_flash) by relative path anyway

and looks like I'm building atmega1280 that builds okay but with atmega128 I got same errors, touche. Need some time to take research

[yonsight]

yes, when I select mega64, no errors.

change the build.cpu= mega16, mega32, mega1280 is ok, but for mega128
still errors.

在 2016-6-21 5:16, Alexander Turkovskii 写道:

Ooops, sorry, I was wrong. It seems I just used make from
WinAVR-20100110\utils\bin\ , but it calls avr-gcc 4.8.1 (that ships
with arduino sdk, Iam building from src placed at
\Arduino\hardware\MightyCore\avr\bootloaders\optiboot_flash) by
relative path anyway

and looks like I'm building atmega1280 that builds okay but with
atmega128 I got same errors, touche. Need some time to take research

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#6 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AGpziJagyb5_2Ionm-Whvj77AcUqSoLsks5qNwMygaJpZM4I4ba8.

[MCUdude]

yes, when I select mega64, no errors.

What version of avr-gcc are you using? (run the command avr-gcc --version)

Here is the output when trying to compile for the ATmega64:

$ make atmega64 AVR_FREQ=16000000L BAUD_RATE=115200 UART=0 LED=B5 LED_START_FLASHES=2 -BIGBOOT
avr-gcc (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

BAUD RATE CHECK: Desired: 115200, Real: 117647, UBRRL = 16, Error=-2.1%
avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -save-temps -mmcu=atmega64 -DF_CPU=16000000L  -DBAUD_RATE=115200 -DLED_START_FLASHES=2    -DLED=B5  -DBIGBOOT -DUART=0   -c -o optiboot.o optiboot.c
optiboot.c:305:2: warning: #warning BAUD_RATE error greater than -2% [-Wcpp]
 #warning BAUD_RATE error greater than -2%
  ^
optiboot.s: Assembler messages:
optiboot.s:26: Error: number must be positive and less than 64
optiboot.s:49: Error: number must be positive and less than 64
make: *** [optiboot.o] Error 1

[sunnyque]

I found reference to this issue and probably the solution in original optiboot thread: https://github.com/Optiboot/optiboot/issues/146
and modified version for at128 here https://github.com/vanbwodonk/optiboot128 (tested, it compiles okay)

[MCUdude]

I used vanbwondonk's ATmega128 bootloader as base when trying to add the flash feature to the bootloader, so the issue should already be solved.. Maybe guru @majekw got a clue? 😉

[majekw]

To do it in right way, a major rewrite of Optiboot is needed (Optiboot/optiboot#148 ) and I don't have a time for this right now.
Quick hack for this issue could be something like that: majekw/optiboot@71fa6f3 - not tested, not compiled, use at your own risk :-), so your feedback will be valuable.

[MCUdude]

Great Majek! It's compiling without errors and reading/writing to flash also works like a charm 👍 Thank you so much! I needed to tweak it a little in order to make it work on the ATmega64.

[MCUdude]

Are there some sort of way to dump the flash content of the microcontroller to a computer without having to hard code this feature in to begin with? I'm thinking of projects where writing to flash may be useful (instead of an SD card). Let's say you've read a sensor for some days and stored the data in the flash. You can always remove the SD card and connect it to your computer, but it's not that easy with the flash memory. I'd like to make an example where data is logged, stored to flash and easily dumped to a computer 😃

[majekw]

Thank you for testing:-)

I have the same problem with my lcd88 - it should allow backup of user data and editing outside transmitter.
I'm thinking about 2 resolutions:

• implement it in internal software and output data on serial with something easy for average user as csv or make some file transfer protocol as x-modem.
• use avrdude to dump all memory and extract part with data from it, for example:
  avrdude -p atmega328p -b 57600 -c arduino -P /dev/ttyUSB3 -U flash:r:dump.hex:i
  You could also dump in raw binary or decimal numbers separated by colons (see man avrdude for available formats).

In both variants it's needed to make some script or application on user side to make it dumb proof :-(

[MCUdude]

The Arduino IDE supports external scripts that makes a procedure like this idiot proof. Have a look at the ESP exception decoder. Is an external script that shows up in the Tools menu.

Is there possible to create some kind of identifier in the binary/hex file so the script "knows" where to start reading from?

[majekw]

Thank you for tip. I didn't know that such thing is possible in Arduino IDE. But I like more idea of making application for Chrome (javascript vs. java):-) At the beginning it will be anyway simple bash script with avrdude and dd inside :-)

If you are making a logger, it should be better to write to flash above code (with some margin between them) and have constant memory location for data.
You could also extract flash location from .lst file. It's also a good idea to ask module somehow about address and size of data. Also putting at the beginning of data some 'magic sequence' is some idea. Plenty of possibilities :-)
It could be perfect if avrdude would accept start/length of memory to read.