[Proposal] Addition of memory "sram" directive

[askn37]

The current "avrdude.conf" has the following description in three places: ".xmega", ".avr8x", and ".avrdx".

    memory "data"
        # SRAM, only used to supply the offset
        offset             = 0x1000000;
    ;

For ".xmega" this is an accurate description. However, this does not apply to ".avr8x" and ".avrdx". They are not XMEGA 32bit address architecture. The correct explanation for them is probably this.

    # AVR16EB14, AVR16EB20, AVR16EB28, AVR16EB32
    memory "data"
        size               = 2048;
        offset             = 0x7800;
    ;

However, with a recent update, the "data" address is now referenced in the "read io" setting. Therefore, this statement is incorrect.

Ideally, "avrdude.conf" should maintain correct memory map information for that part, regardless of who uses that part. Therefore, to ensure the well-being of each part, we propose the creation of a new "sram" directive.

For reference, the SRAM specifications of tinyAVR / megaAVR / AVR_DA / AVR_DB / AVR_DD / AVR_EA / AVR_EB are summarized below.

Please consider it.

KiB	Bytes	Start Address (absolute)	Series
1/8	128	0x3F80	ATtiny202/204 ATtiny212/214
1/4	256	0x3F00	ATtiny402/404/406 ATtiny412/414/416/417
1/2	512	0x3E00	ATtiny804/806/807 ATtiny814/816/817 ATtiny424/426/427
1	1024	0x3C00	ATtiny1604/1606/1607 ATtiny824/826/827 ATmega808/809
2	2048	0x3800	ATtiny1614/1616/1617/3216/3217 ATtiny1624/1626/1627 ATmega1608/1609
2	2048	0x7800	AVR16DDnn AVR16EAnn AVR16EBnn
3	3072	0x3400	ATtiny3224/3226/3227
4	4096	0x3000	ATmega3208/3209
4	4096	0x7000	AVR32DAnn AVR32DBnn AVR32DDnn AVR32EAnn
6	6144	0x2800	ATmega4808/4809
6	6144	0x6800	AVR64EAnn
8	8192	0x6000	AVR64DAnn AVR64DBnn AVR64DDnn
16	16384	0x4000	AVR128DAnn AVR128DBnn

[stefanrueger]

Yes, I thought about that too. And you are right, ideally avrdude.conf describes the part as is in the datasheet and the programmers utilise that information.

We should review the best way to access io memory for all parts

• classic: no external access, bootloader only if at all, I don't know a bootloader using io
• XMEGA: we were unable to find a way to write to io but we can read from io (needs data offset, I think)
• UPDI: some (all?) programmers can r/w io memory; I don't know whether the data offset is needed

I am also not happy about the data memory having zero size and just being a carrier for the offset, which BTW is always 0x1000000 for all 145 known XMEGA and UPDI parts:

$ avrdude -p*/At | grep data.offset | grep -v ' ' | cut -f3- | uniq -c
    145 data    offset  0x1000000

This has low prio for programmers as SRAM is usually volatile and it makes no sense to program it (unless someone has an elaborate bootloader that allows setting of SRAM and/or io memory to initialise them and then jumps to the application, but I haven't come across this, and actually consider this bad practice).

It'll probably be two or three weeks when I can look into this.

@mcuee @MCUdude signing off for the time being (I won't be around in the next weeks)

[askn37]

This has low prio for programmers as SRAM is usually volatile and it makes no sense to program it (unless someone has an elaborate bootloader that allows setting of SRAM and/or io memory to initialise them and then jumps to the application, but I haven't come across this, and actually consider this bad practice).

I just ran into that exact problem. UPDI-compatible chips have a mechanism to externally write arbitrary data to locked non-volatile memory USERRROW. If I use a USERROW-specific authentication key and write it to a "physical address in SRAM" instead of the original address in USRERROW, it works fine. (And UPDI can't read back that memory; it's a one-way street)

Accurate physical SRAM address information is required to support this feature. It's not a virtual address like 0x1000000 that doesn't exist in reality.

I'm currently looking for virtual address 0x1000000 from sources other than what I can get with AVRDUDE, but it doesn't seem to be found in the .atdf file that comes with "pack". So where should we look for its roots?

• Meanwhile, avr-gcc noticed that for links in the ".data" section he was using 0x800000. This setting applies even to the AT90S1200 (__DATA_REGIONLENGTH_\=0 ?), which does not have internal RAM.

Section Name	Region	Define	Logical Address
".text"	Program (Flash)	__TEXT_REGIONORIGIN_\	0x000000
".data"	Data	__DATA_REGIONORIGIN_\	0x800000
".eeprom"	EEPROM	ORIGIN=	0x810000
".fuse"	FUSE	ORIGIN=	0x820000
".lock"	LOCK(LOCKBITS)	ORIGIN=	0x830000
".signature"	SIGNATURE	ORIGIN=	0x840000
".user_signatures"	USERROW	ORIGIN=	0x850000

• This unfortunate problem is probably due to not using memory "io"; start=0x1000000;

++++

As far as I'm concerned,

avrdude -p\*/At | grep data.offset | grep -v ' ' | grep xmega | wc -l
         50

The chip for this condition is memory "io"; start=0x1000000;

avrdude -p\*/At | grep data.offset | grep -v ' ' | grep -v xmega | wc -l
         95

The chip for this condition is memory "io"; start=0;

[stefanrueger]

I have modelled an sram memory in PR #1571. Have a look and try that out, @askn37.

No of parts	SRAM size	SRAM start	Parts
6	0x0020	0x0040	ATtiny4 ATtiny5 ATtiny9 ATtiny10 ATtiny102 ATtiny104
5	0x0020	0x0060	ATtiny11 ATtiny12 ATtiny15 ATtiny28 AT90S1200
2	0x0040	0x0060	ATtiny13 ATtiny13A
1	0x0080	0x0040	ATtiny20
15	0x0080	0x0060	ATtiny22 ATtiny24 ATtiny24A ATtiny25 ATtiny26 ATtiny261 ATtiny261A ATtiny2313 ATtiny2313A AT86RF401 AT90S2313 AT90S2323 AT90S2333 AT90S2343 AT90S4433
4	0x0080	0x3f80	ATtiny202 ATtiny204 ATtiny212 ATtiny214
1	0x0100	0x0040	ATtiny40
10	0x0100	0x0060	ATtiny43U ATtiny44 ATtiny44A ATtiny45 ATtiny461 ATtiny461A ATtiny4313 AT90S4414 AT90S4434 AT90C8534
3	0x0100	0x0100	ATtiny48 ATtiny441 AT90PWM81
8	0x0100	0x3f00	ATtiny402 ATtiny404 ATtiny406 ATtiny412 ATtiny414 ATtiny416 ATtiny416auto ATtiny417
10	0x0200	0x0060	ATtiny84 ATtiny84A ATtiny85 ATtiny861 ATtiny861A ATmega8515 ATmega8535 AT43USB320 AT90S8515 AT90S8535
34	0x0200	0x0100	ATtiny87 ATtiny88 ATtiny167 ATtiny828 ATtiny828R ATtiny841 ATmega8HVA ATmega8U2 ATmega16HVA ATmega16U2 ATmega48 ATmega48A ATmega48P ATmega48PA ATmega48PB AT90PWM1 AT90PWM2 AT90PWM2B AT90PWM3 AT90PWM3B AT90USB82 AT90USB162 ATA5272 ATA5505 ATA5790 ATA5790N ATA5791 ATA5795 ATA6285 ATA6286 ATA6289 ATA6616C ATA6617C ATA664251
9	0x0200	0x3e00	ATtiny424 ATtiny426 ATtiny427 ATtiny804 ATtiny806 ATtiny807 ATtiny814 ATtiny816 ATtiny817
7	0x0400	0x0060	ATmega8 ATmega8A ATmega16 ATmega16A ATmega161 ATmega163 AT43USB355
36	0x0400	0x0100	ATtiny1634 ATtiny1634R ATmega16HVB ATmega16HVBrevB ATmega16M1 ATmega16HVA2 ATmega32U2 ATmega88 ATmega88A ATmega88P ATmega88PA ATmega88PB ATmega162 ATmega164A ATmega164P ATmega164PA ATmega165 ATmega165A ATmega165P ATmega165PA ATmega168 ATmega168A ATmega168P ATmega168PA ATmega168PB ATmega169 ATmega169A ATmega169P ATmega169PA AT90PWM161 AT90PWM216 AT90PWM316 ATA6612C ATA6613C LGT8F88P LGT8F168P
12	0x0400	0x0200	ATA5700M322 ATA5702M322 ATA5781 ATA5782 ATA5783 ATA5831 ATA5832 ATA5833 ATA8210 ATA8215 ATA8510 ATA8515
1	0x0400	0x2000	ATxmega8E5
8	0x0400	0x3c00	ATtiny824 ATtiny826 ATtiny827 ATtiny1604 ATtiny1606 ATtiny1607 ATmega808 ATmega809
1	0x0500	0x0100	ATmega16U4
1	0x07a0	0x0060	AT76C711
3	0x0800	0x0060	ATmega32 ATmega32A ATmega323
31	0x0800	0x0100	ATmega32HVB ATmega32HVBrevB ATmega32C1 ATmega32M1 ATmega324A ATmega324P ATmega324PA ATmega324PB ATmega325 ATmega325A ATmega325P ATmega325PA ATmega328 ATmega328P ATmega328PB ATmega329 ATmega329A ATmega329P ATmega329PA ATmega406 ATmega3250 ATmega3250A ATmega3250P ATmega3250PA ATmega3290 ATmega3290A ATmega3290P ATmega3290PA AT90CAN32 ATA6614Q LGT8F328P
2	0x0800	0x0200	ATA5787 ATA5835
5	0x0800	0x2000	ATxmega16A4 ATxmega16A4U ATxmega16C4 ATxmega16D4 ATxmega16E5
11	0x0800	0x3800	ATtiny1614 ATtiny1616 ATtiny1617 ATtiny1624 ATtiny1626 ATtiny1627 ATtiny3214 ATtiny3216 ATtiny3217 ATmega1608 ATmega1609
11	0x0800	0x7800	AVR16DD14 AVR16EB14 AVR16DD20 AVR16EB20 AVR16DD28 AVR16EA28 AVR16EB28 AVR16DD32 AVR16EA32 AVR16EB32 AVR16EA48
2	0x0a00	0x0100	ATmega32U4 ATmega32U6
3	0x0c00	0x3400	ATtiny3224 ATtiny3226 ATtiny3227
2	0x0fa0	0x0060	ATmega103 AT94K
30	0x1000	0x0100	ATmega64 ATmega64A ATmega64HVE ATmega64C1 ATmega64M1 ATmega64HVE2 ATmega128 ATmega128A ATmega644 ATmega644A ATmega644P ATmega644PA ATmega645 ATmega645A ATmega645P ATmega649 ATmega649A ATmega649P ATmega6450 ATmega6450A ATmega6450P ATmega6490 ATmega6490A ATmega6490P AT90CAN64 AT90SCR100 AT90SCR100H AT90CAN128 AT90USB646 AT90USB647
1	0x1000	0x1000	M3000
18	0x1000	0x2000	ATxmega32C3 ATxmega32D3 ATxmega32A4 ATxmega32A4U ATxmega32C4 ATxmega32D4 ATxmega32E5 ATxmega64A1 ATxmega64A1U ATxmega64B1 ATxmega64A3 ATxmega64A3U ATxmega64B3 ATxmega64C3 ATxmega64D3 ATxmega64A4 ATxmega64A4U ATxmega64D4
2	0x1000	0x3000	ATmega3208 ATmega3209
13	0x1000	0x7000	AVR32DD14 AVR32DD20 AVR32DA28 AVR32DB28 AVR32DD28 AVR32EA28 AVR32DA32 AVR32DB32 AVR32DD32 AVR32EA32 AVR32DA48 AVR32DB48 AVR32EA48
2	0x1800	0x2800	ATmega4808 ATmega4809
3	0x1800	0x6800	AVR64EA28 AVR64EA32 AVR64EA48
2	0x2000	0x0100	AT90USB1286 AT90USB1287
7	0x2000	0x0200	ATmega64RFR2 ATmega640 ATmega644RFR2 ATmega1280 ATmega1281 ATmega2560 ATmega2561
12	0x2000	0x2000	ATxmega128A1 ATxmega128A1revD ATxmega128A1U ATxmega128B1 ATxmega128A3 ATxmega128A3U ATxmega128B3 ATxmega128C3 ATxmega128D3 ATxmega128A4 ATxmega128A4U ATxmega128D4
12	0x2000	0x6000	AVR64DD14 AVR64DD20 AVR64DA28 AVR64DB28 AVR64DD28 AVR64DA32 AVR64DB32 AVR64DD32 AVR64DA48 AVR64DB48 AVR64DA64 AVR64DB64
2	0x4000	0x0100	ATmega1284 ATmega1284P
3	0x4000	0x0200	ATmega128RFA1 ATmega128RFR2 ATmega1284RFR2
10	0x4000	0x2000	ATxmega192A3 ATxmega192A3U ATxmega192C3 ATxmega192D3 ATxmega256A3 ATxmega256A3B ATxmega256A3BU ATxmega256A3U ATxmega256C3 ATxmega256D3
8	0x4000	0x4000	AVR128DA28 AVR128DB28 AVR128DA32 AVR128DB32 AVR128DA48 AVR128DB48 AVR128DA64 AVR128DB64
2	0x8000	0x0200	ATmega256RFR2 ATmega2564RFR2
2	0x8000	0x2000	ATxmega384C3 ATxmega384D3
11	unknown	unknown	ATmega32HVE2 ATmega103comp ATmega161comp AT89S51 AT89S52 AT90S8515comp AT90S8535comp ATxmega192A1 ATxmega256A1 AVR8EA28 AVR8EA32