NEWER New Optiboot bootloader

[westfw]

Ignore it.   The baudcheck feature needs BASH, which probably isn't on your as7 system.
It would be clearer without as7 in there...

[zvipesh]

I am in urgent need for a proven bootloader files for two uP
The uP are working on 12MHz clock - !!!

1) ATmega 2560AU

2) ATmega 1284P

I need these files to be uploaded via ICSP connectors on a custom board.


help will be greatly appreciated.

[subhajitdas298]

Please someone give me compiled bootloader for Atmega8A-PU (16MHz external clock), which I can upload directly.

[pert]

Please someone give me compiled bootloader for Atmega8A-PU (16MHz external clock), which I can upload directly.

https://github.com/MCUdude/MiniCore

[BodyGearable]

Nice post, really its helpfull

[Budvar10]

Stack Pointer init value

I tested something with Atmel Studio 6.1. I realized that the SP in debugging is set to 4101h (ATmega1284P) at start with no prologue code like the optiboot has - without .initN sections.
The optiboot says that it is done by hardware reset (SP = RAMEND) except of ATmega8,16,32. However for the ATmega1284P, the RAMEND is 40FFh, not 4101h.
* Is it bug in AS6.1?
* How about real MCU, is it true that hardware reset initialize the SP to 40FFh? I cannot find info in the datasheet.

[Budvar10]

Interesting finding about SP.
The bootloader starts with this:

Code: [Select]

Disassembly of section .text:
0001fc00 <main>:
int main(void)
{
   1fc00: 00 d0       rcall .+0       ; 0x1fc02 <main+0x2>
   1fc02: 1f 92       push r1
   1fc04: cd b7       in r28, 0x3d ; 61
   1fc06: de b7       in r29, 0x3e ; 62
   ...

The first command executed is RCALL (jump to the next instruction). It decrements SP about 2 and even the SP is 0x4101
at start, after the first instruction it has a value 0x40FF - RAMEND of ATmega1284P.

[westfw]

I realized that the SP in debugging is set to 4101h

Really?  The datasheet I have says pretty clearly that it should be initialized by hardwre to 0x40FF.  Section 7.5.1: "SPH and SPL - Stack Pointer High and Stack pointer Low"   I dunno what debugging is doing...

The first command executed is RCALL (jump to the next instruction).

This is the compiler setting up a stack frame to briefly save one of the local variables (when it could easily have saved it in other ways.)  the "call .+0" is equivalent to the "sub sp, #stackFrameSize" you'd probably see on an ARM, but it's much smaller on the AVR (where SP is off in IO address space, instead of being a register, and can't easily have arithmetic on it.)

This is actually regarded as a bug in optiboot although perhaps it would be more reasonably considered a compiler bug - it showed up in avr-gcc 4.8, got worse in 4.9, and has disappeared in the latest release from Atmel (5.4?)

[Budvar10]

Section 7.5.1: "SPH and SPL - Stack Pointer High and Stack pointer Low"   I dunno what debugging is doing...

My eyes, I am blind...   Now, I remember I had read it years ago. Sometimes happen to me it is hard to remember things after some time.

I am accustomed that AS has exact behaviour as real MCU. Yesterday, I had no HW available, I want test it today.

Thank you WestfW for an explanation. I used avr-gcc 4.7.2 for years and now I'm using 4.9.2 long time.
As I see on Atmel web, there is 3.5.4 latest toolchain and still it uses avr-gcc 4.9.2.
GCC: 4.9.2
binutils: 2.26.20160125
avr-libc: "2.0.0"
gdb: 7.8
You wrote avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.0_487) 5.4.0. Where is?

[Budvar10]

I tested it. SP is initialized with 0x40FF on real ATmega1284P. AtmelStudio has some bug.

[westfw]

As I see on Atmel web, there is 3.5.4 latest toolchain and still it uses avr-gcc 4.9.2.
You wrote avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.0_487) 5.4.0. Where is?

I was a bit surprised at the jump from 4.9 to 5.4 as well.
huh.  The latest Atmel Studio 7 includes the new toolchain (3.6.0.1734):

Atmel Studio 7.0.1416
The following changes are done in Atmel Studio 7.0.1416:

• Changed driver to WinUSB for AVR DragonTM, AVRISP mkII, JTAGICE mkII, JTAGICE3, AVR ONE!, STK®600, and QT600
   :
• Installer improvements
• Improved support for installing older device family packs
• AVR 8-bit GCC Toolchain 3.6.0 with upstream versions:
  
  • -  gcc 5.4.0
  • -  Binutils 2.26.20160125
  • -  avr-libc 2.0.0
  • -  gdb 7.8

And I was able to download the macos version 3.6.0.487 binaries from what I guess is Atmel's Source code distribution site, but I don't see the windows or linux "toolchain" downloads for 3.6.0 in the usual places...

[Budvar10]

Hm, it looks like MAC is little bit ahead. Win & Lnx still refer to older toolchain. I've downloaded AS 7.0.1417 a week ago but have no time to use yet.

[kkchandi]

good luck!

[GoForSmoke]

I guess that I'll find out what's stable over on Github.