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.
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.
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.
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.
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.
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;
}
It's deeply disappointing that Microchip appear to have no quality control in place to catch
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?
Yeah, but this is a whole new level of messing up.
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.
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?
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.
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.
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!
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.
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.
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?
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.
Oh I never thought to check the actual CRT when I built the tests.
CRT???
JIm
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
263If 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 bytesSo 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.
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.
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?
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
I read that discussion in your github repository some time ago. I thought "weird", but that was it
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 work
(do CRTs "think"? Discuss...)
(couldn't find an image of Data with scalp rolled back)
[oops -- never mind]
Next would be Locutus of Borg...
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.
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;
}
Could you check how rjmp fold ? (see#20) my guess is that also will be wrong!
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.
Well, that settles it, the PC has the correct number of bits.
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)
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.
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...
