ATmega809 Interrupt Vectors - Datasheet Error

Go To Last Post
32 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No way to contact Microchip, so I'll leave this here...

 

Section 6.2 of the family data sheet is incorrect for the ATmega809 - the part has <= 8kB of

memory, but the interrupt vectors are every 2nd 16 bit word (second column).  They are not

on 1 word boundaries as listed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The mega409 vector table stores 1-word instructions (rjmp).
Devices with mega809 or higher store 2-word instructions (jmp xx).

 

I don't think it's wrong.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ATmega809 is clearly listed as having 8kB of flash.  https://www.microchip.com/wwwpro...

The table says that 8kB parts use 1-word vector tables.

 

I suspect that the confusion is between 8k words and 8k bytes.  However, the table is specifically in BYTES, and

is wrong.

 

Note that the Microchip-supplied support pack for the ATmega809 is also wrong, containing a vector table on

word boundaries.  I used the ATmega4809 crt file instead, and it works.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh, I made a mistake. mega809 uses a short vector table, otherwise it uses a long vector table.

 

Do you say mega809 uses a long vector table?

How did you confirm that?

I don't have mega809, but I would like to buy and check if you can trust it.

I will not participate if it is simply a matter of writing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

mega809 definitely uses a long vector table - I have an ATmega809 part and wasted most of

a day chasing down why I was getting a BADISR instead of USART0_DRE_vect (supposedly 0x12).  After

brute-forcing to work out the BADISR, I found it was TCB3 Capture (0x24) that was actually

getting called.  After some further investigation, I linked against the crtatmega4809.o file,

which has the vector table on double word boundaries - and it all works.

 

It's deeply disappointing that Microchip appear to have no quality control in place to catch

both the error in the data sheet and the error in the distributed support pack.  It appears

that interrupts have never been tested on this part.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see. I buy mega809.

Then run the following code on a real chip.
The simulator runs Vector12, but I'm looking forward to seeing what happens on the actual chip.

 

#include <avr/io.h>
#include <avr/interrupt.h>

int main(void){
    PORTA.DIRSET = PORTA.OUTCLR = PIN1_bm | PIN2_bm;

    // init
    TCB0_CCMP = 60000;
    TCB0.INTCTRL = TCB_CAPT_bm;
    TCB0.CTRLB  = TCB_CNTMODE_INT_gc;
    TCB0.CTRLA  = TCB_CLKSEL_CLKDIV1_gc | TCB_ENABLE_bm;
    sei();

    while (1){}
}

ISR(TCB0_INT_vect){     // VECTOR12(0x0C, 0x18)
    asm("nop");
    PORTA.OUTSET = PIN1_bm;
}

ISR(PORTC_PORT_vect){   // VECTOR24(0x18, 0x30)
    asm("nop");
    PORTA.OUTSET = PIN2_bm;
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

DrInequality wrote:
It's deeply disappointing that Microchip appear to have no quality control in place to catch
You're new here aren't you ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

You're new here aren't you ;-)

 

Yeah, but this is a whole new level of messing up. One thing is copy/paste of datasheets, but copy/paste of silicon, well...

Because clearly someone copied the HW from a larger chip like the mega4809 and forgot that chips with 8KB or less use short vectors.

 

So, did they also copied the PC and forgot to adjust the number of bits in it, so that rjmp/rcall will not wraparound at flash boundaries, like they are supposed to? Who knows?

 

edit: In fact, did they just changed the signature of a bunch of mega4809 dies, packaged them, and put a mega809 stamp on them?

Last Edited: Tue. Dec 10, 2019 - 09:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:
Yeah, but this is a whole new level of messing up.
No it isn't. There's been copy/paste errors like this since pussy was a kitten. Nothing is new.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, it's interesting that the simulator runs fine, since it's supposedly built from the same hardware description code as the real chips.

I also ordered some samples of mega808 and 809, I want to see this for myself too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So are we saying it's an 8K chip that has full CALL/JMP not just RCALL/RJMP (which is the main reason for the 1 word entries on <= 8K) ?

 

If it does only have RJMP/RCALL I wonder why they waste flash space for spare words that cannot be used?

Last Edited: Tue. Dec 10, 2019 - 10:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This chip has full jmp/call, though these instructions are really not needed because it just has 8KB flash, so rjmp/rcall should be able to reach every part of program memory (unless they messed up the PC too and wraparound is not working).

It's a similar situation to mega88 vs. mega328, chips with 8KB flash or less are supposed to have vector tables where each vector is just 2 bytes, to save flash.

The datasheet, compiler and simulator all agree that the mega809 should have 2 byte vectors, but it seems real hardware has 4 byte vectors. So naturally, the OP spent lots of time wondering why ISRs waren't working properly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:
It's a similar situation to mega88 vs. mega328, chips with 8KB flash or less are supposed to have vector tables where each vector is just 2 bytes, to save flash.
yes but they have different cores. The mega48/88 don't have CALL/JMP

 

In GCC parlance the mega168/328 are "avr5" while the mega48/88 are "avr4" so they have different cores.

EDIT actually this is quite interesting. So when you build for 4809 the .map file says:

LOAD C:/Program Files (x86)/Atmel/Studio/7.0/Packs/atmel/ATmega_DFP/1.3.300/gcc/dev/atmega4809/avrxmega3/crtatmega4809.o

but when you build for 809 it says:

LOAD C:/Program Files (x86)/Atmel/Studio/7.0/Packs/atmel/ATmega_DFP/1.3.300/gcc/dev/atmega809/avrxmega3/short-calls/crtatmega809.o

So both are "avrxmega3" family but note that the 809 is in a "short-calls" sub-directory!

Last Edited: Tue. Dec 10, 2019 - 10:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Good catch. Thanks!

I've reported it internally.

 

The reason the simulator works is that the interrupt vector size is configurable, and the simulator model has the right configuration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd argue that the silicon is correct - and the simulator is wrong - but maybe revised silicon will be forthcoming.

 

Bit mind-boggling that the device support pack for ATmega809 was released without any testing on the actual hardware.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DrInequality wrote:
I'd argue that the silicon is correct - and the simulator is wrong - but maybe revised silicon will be forthcoming.

Silicon is wrong IMO, because for all AVR families I used, it's always the case that if flash<=8K, the MCU has short vectors, including other AVR-0/1 of the tiny series, like tiny817 vs. tiny1617.

 

Yeah, this needs a silicon revision, I don't see how a paragraph in the errata can solve this with a "workaround". What would they say? To link with the mega4809 crt file? Is that really safe?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh I never thought to check the actual CRT when I built the tests. The 809 delivers:

00000000 <__vectors>:
   0:	27 c0       	rjmp	.+78     	; 0x50 <__ctors_end>
   2:	2e c0       	rjmp	.+92     	; 0x60 <__bad_interrupt>
   4:	2d c0       	rjmp	.+90     	; 0x60 <__bad_interrupt>
   6:	2c c0       	rjmp	.+88     	; 0x60 <__bad_interrupt>
   8:	2b c0       	rjmp	.+86     	; 0x60 <__bad_interrupt>
   a:	2a c0       	rjmp	.+84     	; 0x60 <__bad_interrupt>
   c:	29 c0       	rjmp	.+82     	; 0x60 <__bad_interrupt>
   e:	28 c0       	rjmp	.+80     	; 0x60 <__bad_interrupt>
  10:	27 c0       	rjmp	.+78     	; 0x60 <__bad_interrupt>
etc.

the 4809 delivers:

00000000 <__vectors>:
   0:	4f c0       	rjmp	.+158    	; 0xa0 <__ctors_end>
   2:	00 00       	nop
   4:	55 c0       	rjmp	.+170    	; 0xb0 <__bad_interrupt>
   6:	00 00       	nop
   8:	53 c0       	rjmp	.+166    	; 0xb0 <__bad_interrupt>
   a:	00 00       	nop
   c:	51 c0       	rjmp	.+162    	; 0xb0 <__bad_interrupt>
   e:	00 00       	nop
  10:	4f c0       	rjmp	.+158    	; 0xb0 <__bad_interrupt>
  12:	00 00       	nop
  14:	4d c0       	rjmp	.+154    	; 0xb0 <__bad_interrupt>
  16:	00 00       	nop
  18:	4b c0       	rjmp	.+150    	; 0xb0 <__bad_interrupt>
  1a:	00 00       	nop
  1c:	49 c0       	rjmp	.+146    	; 0xb0 <__bad_interrupt>
  1e:	00 00       	nop
...

so certainly the CRTs seem to think (do CRTs "think"? Discuss...) that the 809 is supposed to have short vectors.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Oh I never thought to check the actual CRT when I built the tests.

 

CRT???

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CRT = C RunTime. That is the bit of C that the compiler/library always provides. In an avr-gcc installation there are something like 300 crtXXX.o files, one for each model of AVR. For example in this fairly out of date Arduino installation:

D:\arduino-1.8.8>dir crt*.o /s /b | wc -l
    263

If I just pick one of the 19 different "families" of AVR, in this case "avr4" which is the family that includes atmega48 and atmega88 you will find:

D:\arduino-1.8.8\hardware\tools\avr\avr\lib\avr4>dir crt*.o
 Volume in drive D is DATA
 Volume Serial Number is 1CF4-86D6

 Directory of D:\arduino-1.8.8\hardware\tools\avr\avr\lib\avr4

19/02/2018  11:39             8,128 crtat90pwm1.o
19/02/2018  11:39             2,652 crtat90pwm2.o
19/02/2018  11:39             8,708 crtat90pwm2b.o
19/02/2018  11:39             2,652 crtat90pwm3.o
19/02/2018  11:39             9,508 crtat90pwm3b.o
19/02/2018  11:39             7,308 crtat90pwm81.o
19/02/2018  11:39             7,204 crtata6285.o
19/02/2018  11:39             7,204 crtata6286.o
19/02/2018  11:39             2,440 crtata6289.o
19/02/2018  11:39             7,276 crtata6612c.o
19/02/2018  11:39             7,276 crtatmega48.o
19/02/2018  11:39             7,276 crtatmega48a.o
19/02/2018  11:39             7,276 crtatmega48p.o
19/02/2018  11:39             7,280 crtatmega48pa.o
19/02/2018  11:39             8,072 crtatmega48pb.o
19/02/2018  11:39             5,900 crtatmega8.o
19/02/2018  11:39             5,348 crtatmega8515.o
19/02/2018  11:39             6,304 crtatmega8535.o
19/02/2018  11:39             7,276 crtatmega88.o
19/02/2018  11:39             7,276 crtatmega88a.o
19/02/2018  11:39             7,276 crtatmega88p.o
19/02/2018  11:39             7,280 crtatmega88pa.o
19/02/2018  11:39             8,072 crtatmega88pb.o
19/02/2018  11:39             5,900 crtatmega8a.o
19/02/2018  11:39             2,192 crtatmega8hva.o
              25 File(s)        163,084 bytes

So this particular family has 25 members. If I pick just one of those (e.g. mega8):

D:\arduino-1.8.8\hardware\tools\avr\avr\lib\avr4>avr-objdump -S crtatmega8.o

crtatmega8.o:     file format elf32-avr

Disassembly of section .text:

00000000 <__bad_interrupt>:
   0:   00 c0           rjmp    .+0             ; 0x2 <__FUSE_REGION_LENGTH__>

Disassembly of section .vectors:

00000000 <__vectors>:
   0:   00 c0           rjmp    .+0             ; 0x2 <__vectors+0x2>
   2:   00 c0           rjmp    .+0             ; 0x4 <__vectors+0x4>
   4:   00 c0           rjmp    .+0             ; 0x6 <__vectors+0x6>
   6:   00 c0           rjmp    .+0             ; 0x8 <__vectors+0x8>
   8:   00 c0           rjmp    .+0             ; 0xa <__vectors+0xa>
   a:   00 c0           rjmp    .+0             ; 0xc <__vectors+0xc>
   c:   00 c0           rjmp    .+0             ; 0xe <__vectors+0xe>
   e:   00 c0           rjmp    .+0             ; 0x10 <__vectors+0x10>
  10:   00 c0           rjmp    .+0             ; 0x12 <__vectors+0x12>
  12:   00 c0           rjmp    .+0             ; 0x14 <__vectors+0x14>
  14:   00 c0           rjmp    .+0             ; 0x16 <__vectors+0x16>
  16:   00 c0           rjmp    .+0             ; 0x18 <__vectors+0x18>
  18:   00 c0           rjmp    .+0             ; 0x1a <__vectors+0x1a>
  1a:   00 c0           rjmp    .+0             ; 0x1c <__vectors+0x1c>
  1c:   00 c0           rjmp    .+0             ; 0x1e <__vectors+0x1e>
  1e:   00 c0           rjmp    .+0             ; 0x20 <__vectors+0x20>
  20:   00 c0           rjmp    .+0             ; 0x22 <__vectors+0x22>
  22:   00 c0           rjmp    .+0             ; 0x24 <__vectors+0x24>
  24:   00 c0           rjmp    .+0             ; 0x26 <__FUSE_REGION_LENGTH__+0x24>

Disassembly of section .init2:

00000000 <.init2>:
   0:   11 24           eor     r1, r1
   2:   1f be           out     0x3f, r1        ; 63
   4:   c0 e0           ldi     r28, 0x00       ; 0
   6:   d0 e0           ldi     r29, 0x00       ; 0
   8:   de bf           out     0x3e, r29       ; 62
   a:   cd bf           out     0x3d, r28       ; 61

Disassembly of section .init9:

00000000 <.init9>:
   0:   00 d0           rcall   .+0             ; 0x2 <.init9+0x2>
   2:   00 c0           rjmp    .+0             ; 0x4 <__FUSE_REGION_LENGTH__+0x2>

Then, like all CRT files, what this provides are:

 

a) a jump from 0 to the reset code

b) a fully interrupt vector table all initially linked with a JMP/RJMP to _bad_interrupt (the linker will fill in the "0" targets later once it knows where _bad_interrupt will be placed)

c) the init code that clears R1 to 0x00 (and stores that in SREG to clear the I bit). The compiler then later uses R1 every time it needs a register holding 0x00. After that comes code to set SP to RAMEND (thought the 0x00 won't be replaced with the actual value until linking)

d) finally the stuff in .init9 is where the actual CALL/RCALL to main() will appear but again., in the unlinked .o file the destination just shows as 0 for now as this is yet another linker "fix up" record.

 

When I build the classic empty main() program

int main(void) {
}

for mega8 and the code is finally linked this "template" gets used and filled in as:

Disassembly of section .text:

00000000 <__vectors>:
   0:	12 c0       	rjmp	.+36     	; 0x26 <__ctors_end>
   2:	19 c0       	rjmp	.+50     	; 0x36 <__bad_interrupt>
   4:	18 c0       	rjmp	.+48     	; 0x36 <__bad_interrupt>
   6:	17 c0       	rjmp	.+46     	; 0x36 <__bad_interrupt>
   8:	16 c0       	rjmp	.+44     	; 0x36 <__bad_interrupt>
   a:	15 c0       	rjmp	.+42     	; 0x36 <__bad_interrupt>
   c:	14 c0       	rjmp	.+40     	; 0x36 <__bad_interrupt>
   e:	13 c0       	rjmp	.+38     	; 0x36 <__bad_interrupt>
  10:	12 c0       	rjmp	.+36     	; 0x36 <__bad_interrupt>
  12:	11 c0       	rjmp	.+34     	; 0x36 <__bad_interrupt>
  14:	10 c0       	rjmp	.+32     	; 0x36 <__bad_interrupt>
  16:	0f c0       	rjmp	.+30     	; 0x36 <__bad_interrupt>
  18:	0e c0       	rjmp	.+28     	; 0x36 <__bad_interrupt>
  1a:	0d c0       	rjmp	.+26     	; 0x36 <__bad_interrupt>
  1c:	0c c0       	rjmp	.+24     	; 0x36 <__bad_interrupt>
  1e:	0b c0       	rjmp	.+22     	; 0x36 <__bad_interrupt>
  20:	0a c0       	rjmp	.+20     	; 0x36 <__bad_interrupt>
  22:	09 c0       	rjmp	.+18     	; 0x36 <__bad_interrupt>
  24:	08 c0       	rjmp	.+16     	; 0x36 <__bad_interrupt>

00000026 <__ctors_end>:
  26:	11 24       	eor	r1, r1
  28:	1f be       	out	0x3f, r1	; 63
  2a:	cf e5       	ldi	r28, 0x5F	; 95
  2c:	d4 e0       	ldi	r29, 0x04	; 4
  2e:	de bf       	out	0x3e, r29	; 62
  30:	cd bf       	out	0x3d, r28	; 61
  32:	02 d0       	rcall	.+4      	; 0x38 <main>
  34:	04 c0       	rjmp	.+8      	; 0x3e <_exit>

00000036 <__bad_interrupt>:
  36:	e4 cf       	rjmp	.-56     	; 0x0 <__vectors>

00000038 <main>:
#include <avr/io.h>

int main(void)
{
  38:	80 e0       	ldi	r24, 0x00	; 0
  3a:	90 e0       	ldi	r25, 0x00	; 0
  3c:	08 95       	ret

0000003e <_exit>:
  3e:	f8 94       	cli

00000040 <__stop_program>:
  40:	ff cf       	rjmp	.-2      	; 0x40 <__stop_program>

As you can see in this "empty" program the only thing my main() function has actually created are the opcodes at 38: .. 3C:, everything else came from the CRT.

Last Edited: Tue. Dec 10, 2019 - 04:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it has a HW error , so it use a big ISR table, my bet is that it also have an other error which also change when the program flash is 8K+

 

And that is that the wrap around don't work, RJMP can jump +-2K word and for a 8K chip (in the past at least) that can reach everything, it just wrap around.

 

My guess is that this is a 16K,32k or 48K chip that just have been given a 8k label (ID), and therefor behave as a big chip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
My guess is that this is a 16K,32k or 48K chip that just have been given a 8k label (ID), and therefor behave as a big chip.

 

It's my guess too. The wraparound is achieved by the number of writeable bits in the program counter.

 

Now, this reminds me of something I wanted to test regarding the 48K chips. 48K is not a power of 2, so you can't achieve wraparound at this boundary by just controlling the number of active bits in the PC. I wonder if the mega4809 really wraps around when you reach the end of flash?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I believe I stumbled across the same issue in October, but I didn't think more about it then. I was working on adding Arduino support for the entire megaAVR-0 family when I discovered that millis() micros() and delay() didn't ATmega808 and ATmega809. They did work if I compiled for a 1608/1609 and loaded the hex file directly. I concluded it must be something wrong with the packs or something and kinda forgot about the whole thing, waiting for Microchip to fix this (obvious) issue.

 

The issue from October can be found here: github.com/MCUdude/MegaCoreX/issues/43

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I read that discussion in your github repository some time ago. I thought "weird", but that was itcheeky

 

Now we know the cause. And this will continue causing random errors, incomprehensible without a deep analysis. Many people will not realise that there is something wrong with the vector table.

 

Edit: in fact, kudos to the OP for finding it using just a day's workyes

Last Edited: Tue. Dec 10, 2019 - 08:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


 

clawson wrote:
(do CRTs "think"? Discuss...)

(couldn't find an image of Data with scalp rolled back)

[oops -- never mind]

Next would be Locutus of Borg...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Tue. Dec 10, 2019 - 09:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd be perfectly happy with a Mega0 architecture that said "vectors are always 32bits, even on parts with 8k or less of memory." (there are plenty of ARM chips in the same boat) (and only $0.80 !!)
But getting the documentation and header files right is important!

 

kudos to the OP for finding it using just a day's work

Indeed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ATmega809 has arrived for me.
When I tested, it was exactly what the OP said, and it was different from the data sheet.
The interrupt vector address of TCB0 should be 0x000C, but it has moved to 0x0018 which is the same as ATmega4809.

 

Here is the test code.

#include <avr/io.h>
#include <avr/interrupt.h>

#define PIN_GOOD    PIN0_bm
#define PIN_BAD     PIN1_bm

int main(void){
    // PORT init
    PORTA.DIRSET = PORTA.OUTSET = PIN_GOOD | PIN_BAD;
    // TCB init
    TCB0_CCMP = 60000;
    TCB0.INTCTRL = TCB_CAPT_bm;
    TCB0.CTRLB  = TCB_CNTMODE_INT_gc;
    TCB0.CTRLA  = TCB_CLKSEL_CLKDIV1_gc | TCB_ENABLE_bm;
    sei();
    while (1);
}

// Good Vector (0x0C(W), 0x18(B))
ISR(TCB0_INT_vect){
    PORTA.OUTCLR = PIN_GOOD;    // PA0:Green LED
    TCB0.INTFLAGS = TCB_CAPT_bm;
}

// Bad Vector (0x18(W), 0x30(B))
ISR(PORTC_PORT_vect){
    PORTA.OUTCLR = PIN_BAD;     // PA1:Amber LED
    TCB0.INTFLAGS = TCB_CAPT_bm;
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Could you check how rjmp fold ? (see#20) my guess is that also will be wrong!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I made the section ".test" the program address 0x900. And I put an ISR in that section.

rjmp goes in the negative direction. And it worked fine.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, that settles it, the PC has the correct number of bits.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Install the latest Atmel.ATmega_DFP, 1.4.346, from http://packs.download.atmel.com, which has an update interrupt structure matching the device... (ref comment in https://www.avrfreaks.net/comment/2817071#comment-2817071)

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr-gcc is wrong as it is basing on the wrong assumption that the data sheets are reliable. My bad.
.
Dunno what's the best approach. Could move ATmega808/809 to a different multilib variant (no -mshort-calls) or extend avr-libc's gcrt1.S and pass extra options in gen-avr-lib-tree.sh.

avrfreaks does not support Opera. Profile inactive.

Last Edited: Sun. Dec 22, 2019 - 10:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's a nice bug, I would call it a feature :-)

Really, I always hated that the 48/88 are not binary compatible with 168/328...