Go Down

Topic: NEWER New Optiboot bootloader (Read 97946 times) previous topic - next topic

somedude

Bill,


Would you mind clarifying one thing?

I tried compiling Optiboot for my 1284p and on github, your boards.txt has this comment and low fuse setting:

# Select full swing crystal oscillator (7F rather than FF)
optiboot1284.bootloader.low_fuses=0x7F

If I look at the fuse calculator here it looks like:
0x7F has CKDIV8 enabled and 0xFF is External Crystal
Now full swing appears to be 0xF7 without changing anything else, so is this a late-night typo?

Thank you very much.


westfw

Quote
Now full swing appears to be 0xF7 without changing anything else, so is this a late-night typo?
Yes, it appears so.  I have the F7 value in the *_isp targets in the Makefile, but the wrong values in boards.txt.
Sigh.  I've created https://github.com/Optiboot/optiboot/issues/174


somedude

#47
Feb 02, 2016, 03:41 pm Last Edit: Feb 02, 2016, 04:32 pm by somedude
I hate to bug you again, but I had trouble burning the bootloader to my 1284P, so I attempted some troubleshooting and read a bunch of other things.

Since lock bits are not clear in my mind, I will simply state my findings, without attempting to comment.
So here it is: maniacbug has the lock bits as 0x0F instead of 0x2F. I was getting a verification error when attempting to burn the bootloader with 0x2F for the lock bit, but I was successful with 0x0F.

I will do some reading in an attempt to understand the lock bits, but I thought I should mention this.
And I apologize for not specifying earlier that I am looking at boards.txt for 1.6



Edit: After spending some time reading the datasheet, I think this is what needs to happen:
Unprogramming (1) bootloader lock bits BLB11 and BLB12 (0x3F) removes any restrictions accessing the boot loader, necessary to be able to write it to the chip.
Programming (0) them both (0x0F) locks writing to the boot loader and reading from it as well.
Only programming BLB11 (0x2F) just locks the bootloader for writing.

So, if I understand this correctly, both 0x0F and 0x2F lock the bootloader for write, which makes sense so that it doesn't get wiped out, but 0x2F allows the program to read from it.

In my case, both lock bit settings should have worked, as both are valid.
I will go back to 0x2F and retry, maybe I messed something else up.


Edit (again - sorry): It worked with 0x2f, so it was me.

Sorry for wasting your time.

somedude

Update - for the sake of closure, I wanted to explain how I got Optiboot compiled for my 1284p.

RTFM was the key here, but I was unable to upload a sketch until I overrode the baud rate.
I noticed that Arduino writes at 19200 through the programmer, so I used that baud rate as a compile option and it finally took the sketch.

Thank you very much for Optiboot, it is amazing.

srinivardhan

Hi,

I thought I should write my own boot loader so that I could boot load through UART1 instead of UART0. I want to flash my hex file via  a bluetooth module HC 05. But then I found bootloader called optiboot. Will the 1284 optiboot compiled for UART1 instead of UART0 (EXPERIMENTAL!) present in the https://code.google.com/archive/... suffice my need ?

I was told by AVR clawson to sort it out with westfw :)
 
I want to run at 9600 baud rate. Do I need to make any changes to the source code and if so how ?
 
Looking forward to hear from you,

Party_Waffel

#50
Feb 18, 2016, 06:32 pm Last Edit: Feb 18, 2016, 08:57 pm by Party_Waffel
Hi,

I've recently managed to install optiboot on an arduino nano with an ATmega328p. It works perfectly except when I power the board with my laptop via a usb cable. When I do so, the arduino flashes the led at pin 13 several times before executing the sketch. It executes the sketch instantly when powered vie the VIN pin though. I've no idea what's causing this.

Video D13 led is the lowest one. The sketch is supposed to turn leds connected to a shift register on and off.

Thanks in advance

EDIT: the sketch loads instantly when powered by the laptop when laptop is in sleep mode. I guess it waits for serial communication before running the sketch.

westfw

if there is something on your laptop that actually starts serial communication, it is normal for this to cause a reset and run the bootloader (causing the three flashes) (whereas a clean power-on with no serial involvement SHOULD go direct to the sketch.)  This is due to the auto-reset circuitry of the Arduino.  (which is somewhat sensitive; it wouldn't surprise me of certain power-up situations result in an "external reset" rather than a "power on" reset.  I'm not sure whether USB enumeration (without actually opening the serial port) will do anything.  But it's possible.)

Party_Waffel

Thanks for the quick reply, I've tried turning DTR off and shorting the RST pin to the GND pin with a 10uF capacitor as stated in the serial auto reset disable guide but those didn't help either. What confuses me is that this doesn't happen at all with my uno v3 which also has optiboot installed.

DavidI

Thanks for the quick reply, I've tried turning DTR off and shorting the RST pin to the GND pin with a 10uF capacitor as stated in the serial auto reset disable guide but those didn't help either. What confuses me is that this doesn't happen at all with my uno v3 which also has optiboot installed.
From my experience using the UNO V3 as an ISP programmer, and from what I've read, the V3 doesn't need the 10uF nor does it seem to be needed with the Pro mini I'm actually using as an ISP programmer.  In both cases the DTR was left enabled.
Dave

beic

Hi there,

I'm searching HEX file for the ATmega8-16PU MCU named "optiboot_atmega8-16.hex", can someone please upload it?

I was unable to find on the internet!

I need it for this entry to be able to burn Bootloader to my fresh ATmega8-16PU's!

Code: [Select]

##############################################################
opti8.name=Arduino Optiboot-Atmega8-16
opti8.upload.protocol=arduino
opti8.upload.maximum_size=7680
opti8.upload.speed=115200
opti8.bootloader.low_fuses=0xbf
opti8.bootloader.high_fuses=0xcc
opti8.bootloader.path=optiboot
opti8.bootloader.file=optiboot_atmega8-16.hex
opti8.bootloader.unlock_bits=0x3F
opti8.bootloader.lock_bits=0x0F
opti8.build.mcu=atmega8
opti8.build.f_cpu=16000000L
opti8.build.core=arduino
opti8.build.variant=standard
##############################################################


Thank you!
..:: <3 I love this beautiful world <3 ::..

westfw

#55
Jun 06, 2016, 02:34 am Last Edit: Jun 06, 2016, 02:36 am by westfw Reason: Edit: it won't let be attach .hex files. Zipped.
Here it is.  I'm not sure where you got that boards.txt file from; I'm pretty sure that the atmega8 hex file has never had the -16 suffix (somewhat irrelevant since the currently provided .hex files don't include any atmega8 binaries.)
You'll probably have trouble using the "burn bootloader" command with any modern IDE; atmega8 has been broken for a long time.  Using my OptiLoader Or Nick's (enhanced!) Bootloader programmer would be easier...

Edit: it won't let be attach .hex files.  Zipped.


beic

Here it is.  I'm not sure where you got that boards.txt file from; I'm pretty sure that the atmega8 hex file has never had the -16 suffix (somewhat irrelevant since the currently provided .hex files don't include any atmega8 binaries.)
You'll probably have trouble using the "burn bootloader" command with any modern IDE; atmega8 has been broken for a long time.  Using my OptiLoader Or Nick's (enhanced!) Bootloader programmer would be easier...

Edit: it won't let be attach .hex files.  Zipped.


Hi westfw,

I was Googling a few day now to find the easiest and the best solution and I came a cross to this page on Instructables.

And I got that boards.txt entry from that post, but it was strange to me also because of that suffix.

Thank you for your fast reply!  8)
..:: <3 I love this beautiful world <3 ::..

beic

Here it is.  I'm not sure where you got that boards.txt file from; I'm pretty sure that the atmega8 hex file has never had the -16 suffix (somewhat irrelevant since the currently provided .hex files don't include any atmega8 binaries.)
You'll probably have trouble using the "burn bootloader" command with any modern IDE; atmega8 has been broken for a long time.  Using my OptiLoader Or Nick's (enhanced!) Bootloader programmer would be easier...

Edit: it won't let be attach .hex files.  Zipped.


Me again and confused a little bit.

In the Arduino's "hardware\arduino\avr\bootloaders\optiboot\" there is a HEX file optiboot_atmega8.hex and it's 1.36Kb (CRC32: 6d4bc037), but what I got from your zip file is optiboot_atmega8-16.hex and it's 1.28Kb (CRC32: 1336439d), so what is basically the difference between those two HEX files?

Thank you!
..:: <3 I love this beautiful world <3 ::..

westfw

The Optiboot from the IDE is version 4.4; the .hex file I posted is version 6.2 ...
There are probably not any changes that are particularly relevant to the m8 (ie no reason to use the newer one)
Most of the edits have added other chips, corrected for new compiler behavior, or enhanced the build system.
(You can view the edits at https://github.com/Optiboot/optiboot

Maverick71

#59
Jun 10, 2016, 08:04 pm Last Edit: Jun 10, 2016, 08:50 pm by Maverick71
Hello,

I just saw You made support for the 328PB Chip.

I asked this some time ago, but did NOT got definitive answer.

Can be those boatloader used in commercial Products like Arduino UNO "clones"?
Which kind of bootloader those boards from China are using as bootloadeR?

Regards,
Maverick

Go Up