NEWER New Optiboot bootloader

Silly question alert...

I've just grabbed a 1284 with optiboot on it, which seems to have a somewhat messy pin layout. I understand this is mapped from the base AVR ports (probably wrong terminology).

Anyway, Im trying to understand where things like the external interrupts are mapped, is this anything I could read myself to see where they are(eg from a config file somewhere)?

PS. pinout from top left:

D4--------A7/D21
D5--------A6/D20
D2--------A5/D19
D3--------A4/D18
D10-------A3/D17
D11-------A2/D16
D12-------A1/D15
D13-------A0/D14
RST--------Aref
Vcc--------GND
GND-------AVcc
XTAL2-----D29
XTAL1-----D28
D0/Rx0----D27
D1/Tx0----D26
D6/Rx1----D25
D7/Tx1----D24
D30-------D23
D8--------D22
D9--------D31

ATmega pins have several functions and they are hardwired to ATmega's pins. The external interrupts are alternative functions of I/O. The datasheet of ATmega describes the mapping. If you have known pin mapping to Arduino it is not a problem to find out where the ext. interrupt is. For an example: INT0 is on the PD2 of ATmega1284P (pin 16 on DIL package) . There are also RXD1 and PCINT26 functionality and according your map it is D6 on Arduino.

I've had a mega2560 for a couple of years and reverse engineered an avrdude subset to upload sketches to it as part of a larger software project. It used stk500v2 programming. Just got a new UNO R3, which programs fine with Arduino 1.6.9. IT uses stk500/optiboot programming sequences. But my old uploader also sort of works, and there is no code in optiboot to recognize v2 sequences! I've added timing measurement to my own v2 uploader, and the first packet (v2 logon) doesn't get picked up for about 100 ms. Then it loads fine, but every 8 packets (1024 bytes) there is a 6 sec delay before the next packet is accepted.

One of my goals in this is to be able to power on/off the board while debugging hardware w/o having to deal with the IDE and its concept of serial ports (moving USB target on Linux)..My own uploader pokes around and finds the new /dev/ttyACMx port without my intervention. So 2 issues:

  1. why does my loader work at all? The IDE generates 2 hex files, one with bootloader(?) and one without. This is new - could the "bootloader" stuck in the sketch be a v2 loader that runs as an application after a timeout??? Or what?

  2. I'm prepared to add stk500 (v1) code to my uploader - it's simpler than the v2. But is there a way to detect WHICH format to send - without the tables of magic numbers for each board/mcu/etc that seems to be how the current software is designed.

If there's a 6-second delay, that almost certainly means that the Uno is resetting and starting over. What makes you think that it's "working" ? Have you uploaded and successfully run a sketch larger than 1024 bytes? (IMO, it SHOULDN'T work at all. v2 wraps everything into "packets" so that the receiver can check CRC/etc. v1 doesn't understand those...)

I think v2 sends a startup string at poweron, while v1 is quiet until the PC sends it commands...

I am trying to load the optiboot bootloader to a arduino nano. when building the project with AtmelStudio 7
it reports:

Error recipe for target 'baudcheck' failed xplained328pb C:\Users\Jan\Documents\Arduino\optiboot-master\optiboot\AtmelStudio\Makefile 519

Any idea how to correct this ?

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

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.

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

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

Nice post, really its helpfull

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.

Interesting finding about SP.
The bootloader starts with this:

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

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?)

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... :o 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?

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

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

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.

good luck!

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

hi
is *A-PU supported by optiboot?