I am puzzled... A corrupted parameter passed to a function in an AVR64DD32 project

[akouz]

Hi All,
I use DxCore in a AVR64DD32 project. Project description is here

There is a function to write a buffer into an external I2C EEPROM:
write_EE(uchar* buf, uint addr, uchar len);

It works fine when I call it in all cases except one. In one case when I call this function, it receives NULL instead of pointer buf. My procedure handles NULL pointer in a specific way: it writes 0xFF into EEPROM, this is how I could detect that it was wrong.

Byte array buf in the calling function is local for calling function. If I make it global then my function works correctly. Other calling functions can use the write_EE functions with locally declared buffers, no problems.

So, basically, when I call write_EE(uchar* buf, uint addr, uchar len); function from one place in my code, it somehow corrupts pointer. When I call it from other places it works OK.

I compile project with Arduino 1.8.6, DxCore 1.5.6.

[SpenceKonde]

I think that this is almost certainly a bug in the C code.

1. We require Arduino 1.8.13 or later for best results; 1.8.13 was the first one that fixed the displaying of programmers list in tools -> programmers. That came out over 3 yearso ago, and 2 years or so ago we removed the workaround for that behavior to reduce visual clutter in response to user feedback. So on 1.8.6, I expect trouble uploading (there will be multiple instances of programmers with the same name, each corresponding to a core. Only ones packaged with this core will work. On 1.8.13 and later, the ones that aren't supplied by the core and thus which will not work are not shown (though when you switch between cores, you always have to reselect the programmer (and it will show up blank in the dropdown menu).

• Note that the 2.x.x versions of the IDE are still buggy, and last I checked the latest couldn't install third party hardware packages. So I'd recommend 1.8.13 or 1.8.19.

2. You are using an old version of the core. A lot has been touched since 1.5.6 (though what little evidence you present thus far has given no reason to suspect a bug in the core, nor are there any plausible candidates. But you've given very little information). Also, link to the code, I don't know where in the repo to get your test case that reproduces this. See list below.

3. This has all the hallmarks of a C bug in your code - and you've given no indication that any core code is involved - presumably Are you sure you're not smashing the stack or something? Maybe an out of bounds write? That would have different effects depending on where in memory it was located. Could you have two variables with different scopes and the same or very similar names that your code is confusing? Is the one case where it fails an outlier in any way? What are the lengths of the buffer being written, etc? print out debugging info, and track the null pointer upstream - Serial.print((uint16_t)buffptr); Write_EE(...), and have Write_EE() also print out it's arguments. If the pointer is zero in both, move your prints upstream until you find out when and why it becomes null or ceases to not be null. If neither are zero, your null trap is broken. If the first is not 0 but the second is (that is, between the last line before Write_EE and the first line of Write_EE)

Changes since 1.5.6

• 1.5.11 (Emergency fix)
  • At some point in the recent past, I must have angered the gods of C, and suddenly millis disabled stopped working - the system would hang (actually, with in-depth investigation, it was shown to be bootlooping - before it called init(), it was calling 0x0000 (a dirty reset) instead of eliding a weakly defined function with nothing in the body except a return, or with an empty body. Why was it doing this? And why only when millis was disabled?). millis disabled is a key piece of core functionality, necessitating an urgent fix. Moving the definitions into main.cpp resolved this issue. (millis/micros timer disabled wedges DD part #485)
  • Critical PWM bug on DA and DB returned and made all TCA and TCD PWM fail to operate. (PWM on TCA0 and TCA1 does not work (name edited) #473)
  • Comparator voltage reference table was incorrect, so unexpected behavior was observed when selecting most references. (Comparator Reference Voltages Incorrect? #488)
  • Azduino7b1 toolchain version to fix bad power.h and eeprom.h. 7a was never released and was windows-only fix to the package files which had extra files included, 7b was the fix that also corrected the two builtin headers, but specified the crc for 7a, and could not be installed. 7b1 simply corrects that, but you can't take things out of the json file, only add them (the user-visible aspects of this issue manifest on several parts that we don't support for power.h, and eeprom.h (not EEPROM.h - that was impacted by a different bug not long ago). (EEPROM with new AVR EA CPU #482)
• 1.5.10 (Emergency fix)
  • Enhancement/bugfix - add digitalPinToCanon() - given a pin number, it returns port * 8 + bit_position. This is to be used in some other fixes and enhancements.
  • Workaround Arduino CLI regression impacting CI testing.
  • Correct bug preventing compilation of any sketches discovered as soon as the CI was working.
  • Actually use the new toolchain, which we weren't doing, and I didn't realize until the CI was working.
• 1.5.9
  • Bugfix: Correct Flash.h issues.
  • Bugfix: Remove boot_opt.h which is not applicable to modern AVRs.
  • Bugfix: Remove the useless dummy app that forced us to use avr-size -A to see the size of the bootloader separated from the app, and switch avr-size -A to normal avr-size to take advantage of this.
  • Maintenance - Rebuilt all bootloaders in support of above fix.
  • Docs: Major updates across the board
  • BugFix - Correct critical defect in disabled millis.
  • Enhancement - implement _getCurrentMillisTimer() and _getCurrentMillisState() which are/will be required for sleepTime.h
  • Bugfix - Optiboot did not honor entry conditions (Update parse_options.mk #452), bump optiboot version to 0x1A02.
  • Maintenance - Rebuilt all bootloaders again.
  • Enhancement Add CORE_HAS_ERRORFUNS #define. Add CORE_HAS_MILLISSTATE #define.
  • Bugfixes, several, for SerialUPDI, and improvements in error messages.
  • Enhancement - Add the 16k and 32k EA-series parts. Still no 8k ones or headers for them either.
  • Maintenance - add CI testing for EA-series parts.
  • Bugfix: Correct compilation when analogWrite() was used on AVR EA.
  • Bugfix: Add missing API extensions on EA-series for ADC.
  • Bugfix: Fix Comparator, Event, and SPI and Wire up well enough that things at least compile on EA. And in the case of comparator, SPI, and Wire, I'm pretty sure they work too.
  • Maintenance - Correct CI testing to specify valid option for flmap menu.
  • Enhancement - (also makes the CI easier) Lay ground work for future library support for a Flash.h for Ex-series.
  • Bugfix: Optiboot boards did not honor the FLMAP option.
  • Enhancement - Update forward looking EB-series defines now that headers have escaped (here's the bad news: 4 independent channels only, half of the WO channels are inverted waveforms with dead time insertion for PSC and BLDC drive applications - and TCF at most gets you 2 8-bit channels through a TCB-like method - it's meant for generating square waves or periodic pulses. The quality of the 4 good PWM channels we get may be unmatched (we'll need to see the docs - but it looks like 19-bit PWM resolution may be in the cards with HIRES. That will have to wait until we have datasheets though.
  • Bugfix - in several cases it was possible to, using third party IDEs, pass incompatible options to the core. This now produces a more helpful error message. (USING TIMERA0 WITh AVRXXDD20 get error #477)
• 1.5.8
  • Bugfix - Change clockCyclesToMicroseconds, microsecondsToClockCycles, and clockCyclesPerMicrosecond back into macros instead of inlinable functions, as some libraries depend on them being valid constexprs.
  • Bugfix - pinModeFast will now turn off pullups if they're on when a pin is set to output. otherwise, the result was problemaic for - for example, a situation I ran into where the pullup was never turned off even after the pins were set back to output and driven low. Prior to going to deep sleep. You can imagine what my battery life was like.
  • Bugfix (serious) - ensure that compilation will succeed on Optiboot DD-series devices.
  • Bugfix - Remove the Optimization Level menu - it caused too many problems that I didn't know how to solve (nothing with serial would compile if not set for -Os - in order to gain large improvements in performance and reduction in flash usage, some of the methods used are not entirely above board.
  • Bugfix - tinyNeoPixel timing issues at 20-32 MHz should be corrected now tinyNeoPixel has issues at 24 MHz #421
  • Bugfix - Add updateLatch(uint8_t) method. This takes an argument (in microseconds) that sets the blackout period after show() is called, since in the wild parts with between 6 and 250 us of latch delay exist, and parts that match the previous implementation may be outnumbered by ones which do not).
  • Bugfix - Fix issue when serial buffer is set to the maximum. Error compile when change SERIAL_RX_BUFFER_SIZE to 256 #428
  • Large number of documentation clarifications.
  • Bugfix - Realized that the PROGMEM_MAPPED directive was dangerous because we defined it even if the FLMAP was not locked. Added a new menu to allow user to either lose PROGMEM_MAPPED, or pick a flash section to map and let us set and lock FLMAP during init, and get PROGMEM_MAPPED pointing where it should.
  • BETA BETA BETA Add EA-series non-optiboot boards to the board selection menu. The update where we will expect them to be 100% (well, whatever % working you happen to expect from DxCore) will be numbered 1.6.0, but by pushing an update that lets you attempt unsuccessfully to use the new parts, we can expedite development.
  • RESEARCH Added the reserved values for BOD level. Get out there, try them and see what voltage they set the BOD to, if any. If any turn out to be useful, they'll stay in, otherwise, out they go.
  • Documentation - Errata: all evidence I have been able to gather indicates a novel silicon bug on the AVR DD-series parts with TWI mux option to. It seems to drive the SDA line low to generate the start condition. but that's as far as it gets. The clock never changes. This is a rather serious issue, as it means that the MVIO pins aren't available for TWI. This behavior is not observed consistently and I cannot reconcile that with the nature of reality.
  • Bugfix - Correct bootloaders for 32k DA, DB, DD parts, which had been incorrectly reporting the signature of the chip.
  • Bugfix - Flash.h wasn't recognizing recent version of the bootloader.
  • Bugfix - Remove the stupid dummy app from the optiboot source (it was totally unnecessary)
  • Azduino7 Toolchain package.

[akouz]

Hi SpenceKonde,

Thank you very much for your comprehensive reply.

Probably you are right, there is a bug in my code somewhere. But it is a tricky one. I noticed an unstable behavior of the sketch a while ago. Strange things appear and disappear without any obvious correlation to the changes I do in the code. This time at least I can control it somehow: it can be reproduced, and a small change makes it disappear.

The sketch is not too big:

Sketch uses 27836 bytes (43%) of program storage space. Maximum is 64512 bytes.
Global variables use 3152 bytes (38%) of dynamic memory, leaving 5040 bytes for local variables. Maximum is 8192 bytes.

The sketch HBnode_DD32 is here. However, it would not be so easy to reproduce it by someone else because it employs a custom bootloader with size of 1K. Thus, DxCore "boards.txt" needs to be modified. To upload a compiled sketch to the board one would need a custom programmer with appropriate PC application. Sketch has a monitor connected to a PC hyperterminal via a I2C-to-serial converter FT200XD. It is not a standard converter because I2C in the FT200XD is a slave rather than a master. All together amount of specific hardware is a bit excessive to reproduce. So, I'd rather show my observations.

For instance, when I upload a new compiled sketch via HBus, the current sketch stores the new code in a serial EEPROM. The new code is sent to the node in 32-bytes chunks, and the current sketch stores those chunks in EEPROM using the mentioned in my previous post uchar I2Cbb::write_EE(uchar* buf, uint adrr, uchar len) function (see "i2c_bitbang.cpp" file). During download the calling function is uchar HB_cmd::rply_boot(hb_msg_t* rxmsg, hb_msg_t* rply) (see file "HBcmd.cpp").

When code is uploaded to EEPROM, the last 8-byte chunk stored in EEPROM at address 0x0010. It is a descriptor. First four byte are a pattern 0xAA, 0x55, 0xC3, 0x3C. The pattern indicates to the bootloader that a new code is stored in EEPROM and it should be copied into the AVR flash. Next two bytes is code length, starting from address 0x400. The last two bytes are crc for the stored code.

Before writing the last chunk to the EEPROM, sketch checks crc and, if matches, stores descriptor in EEPROM and after a delay resets AVR.

At wake-up bootloader checks EEPROM descriptor at address 0x0010. If there is the required pattern there, bootloader copies EEPROM to AVR flash, clears the pattern in the EEPROM and resets. If there is no required pattern there, bootloader passes control to the sketch at address 0x400.

After wake-up sketch prints a wake-up message. Monitor command EErd prints content of EEPROM descriptor (address 0x10, length 8 bytes)

Everything as expected.

To be continued in the next post...

[akouz]

The problem arises when I use the function uchar I2Cbb::write_EE(uchar* buf, uint adrr, uchar len) in other place.

For the sake of debug, I implemented monitor command reset, see void Mon::reset(void) in the "HBmonitor.cpp" file. Command 1 reset resets AVR after delay of 20 ms, command 2 reset resets AVR instantly. Command 3 reset should fill EEPROM descriptor with the pattern 0xAA, 0x55, 0xC3, 0x3C.

But it does not. After executing 3 reset result is not as expected:

[akouz]

As far as I understand, compiled code should fill registers R20, R22, R23, R24, R25 before calling function I2Cbb::write_EE. The following are related snapshots from the listing:, usually it is more or less transparent:

rdwr_sn():
    2bb0:	44 e0       	ldi	r20, 0x04	; 4
    2bb2:	60 e4       	ldi	r22, 0x40	; 64
    2bb4:	70 e0       	ldi	r23, 0x00	; 0
    2bb6:	ce 01       	movw	r24, r28
    2bb8:	87 54       	subi	r24, 0x47	; 71
    2bba:	9f 4f       	sbci	r25, 0xFF	; 255
    2bbc:	0e 94 ed 05 	call	0xbda	; 0xbda <I2Cbb::write_EE(unsigned char*, unsigned int, unsigned char) [clone .constprop.114]>

rdwr_id():
    2c7a:	42 e0       	ldi	r20, 0x02	; 2
    2c7c:	68 e4       	ldi	r22, 0x48	; 72
    2c7e:	70 e0       	ldi	r23, 0x00	; 0
    2c80:	ce 01       	movw	r24, r28
    2c82:	8b 54       	subi	r24, 0x4B	; 75
    2c84:	9f 4f       	sbci	r25, 0xFF	; 255
    2c86:	0e 94 ed 05 	call	0xbda	; 0xbda <I2Cbb::write_EE(unsigned char*, unsigned int, unsigned char) [clone .constprop.114]>

rdwr_str():
    2d52:	41 e0       	ldi	r20, 0x01	; 1
    2d54:	4e 0f       	add	r20, r30
    2d56:	6c ef       	ldi	r22, 0xFC	; 252
    2d58:	6d 0d       	add	r22, r13
    2d5a:	70 e0       	ldi	r23, 0x00	; 0
    2d5c:	6c 5f       	subi	r22, 0xFC	; 252
    2d5e:	7f 4f       	sbci	r23, 0xFF	; 255
    2d60:	56 e0       	ldi	r21, 0x06	; 6
    2d62:	66 0f       	add	r22, r22
    2d64:	77 1f       	adc	r23, r23
    2d66:	5a 95       	dec	r21
    2d68:	e1 f7       	brne	.-8      	; 0x2d62 <coos_task_1ms()+0x878>
    2d6a:	f7 01       	movw	r30, r14
    2d6c:	82 8d       	ldd	r24, Z+26	; 0x1a
    2d6e:	93 8d       	ldd	r25, Z+27	; 0x1b
    2d70:	0e 94 ed 05 	call	0xbda	; 0xbda <I2Cbb::write_EE(unsigned char*, unsigned int, unsigned char) [clone .constprop.114]>

etc

But for some reason in the reset function it is drastically different:

reset():
    300e:	eb e8       	ldi	r30, 0x8B	; 139
    3010:	f8 e6       	ldi	r31, 0x68	; 104
    3012:	14 89       	ldd	r17, Z+20	; 0x14
    3014:	11 30       	cpi	r17, 0x01	; 1
    3016:	09 f0       	breq	.+2      	; 0x301a <coos_task_1ms()+0xb30>
    3018:	47 c0       	rjmp	.+142    	; 0x30a8 <coos_task_1ms()+0xbbe>
    301a:	80 81       	ld	r24, Z
    301c:	91 81       	ldd	r25, Z+1	; 0x01
    301e:	81 30       	cpi	r24, 0x01	; 1
    3020:	91 05       	cpc	r25, r1
    3022:	41 f4       	brne	.+16     	; 0x3034 <coos_task_1ms()+0xb4a>
    3024:	81 e4       	ldi	r24, 0x41	; 65
    3026:	94 e6       	ldi	r25, 0x64	; 100
    3028:	0e 94 ea 05 	call	0xbd4	; 0xbd4 <I2Cbb::println(char*) [clone .constprop.115]>
    302c:	82 e0       	ldi	r24, 0x02	; 2
    302e:	80 93 98 6b 	sts	0x6B98, r24	; 0x806b98 <node+0xb3>
    3032:	38 cd       	rjmp	.-1424   	; 0x2aa4 <coos_task_1ms()+0x5ba>
    3034:	82 30       	cpi	r24, 0x02	; 2
    3036:	91 05       	cpc	r25, r1
    3038:	49 f4       	brne	.+18     	; 0x304c <coos_task_1ms()+0xb62>
    303a:	81 e4       	ldi	r24, 0x41	; 65
    303c:	94 e6       	ldi	r25, 0x64	; 100
    303e:	0e 94 ea 05 	call	0xbd4	; 0xbd4 <I2Cbb::println(char*) [clone .constprop.115]>
    3042:	88 ed       	ldi	r24, 0xD8	; 216
    3044:	84 bf       	out	0x34, r24	; 52
    3046:	10 93 41 00 	sts	0x0041, r17	; 0x800041 <__TEXT_REGION_LENGTH__+0x7f0041>
    304a:	2c cd       	rjmp	.-1448   	; 0x2aa4 <coos_task_1ms()+0x5ba>
    304c:	03 97       	sbiw	r24, 0x03	; 3
    304e:	61 f5       	brne	.+88     	; 0x30a8 <coos_task_1ms()+0xbbe>
    3050:	81 e2       	ldi	r24, 0x21	; 33
    3052:	94 e6       	ldi	r25, 0x64	; 100
    3054:	0e 94 ea 05 	call	0xbd4	; 0xbd4 <I2Cbb::println(char*) [clone .constprop.115]>
    3058:	85 e5       	ldi	r24, 0x55	; 85
    305a:	cf 54       	subi	r28, 0x4F	; 79
    305c:	df 4f       	sbci	r29, 0xFF	; 255
    305e:	88 83       	st	Y, r24
    3060:	c1 5b       	subi	r28, 0xB1	; 177
    3062:	d0 40       	sbci	r29, 0x00	; 0
    3064:	8a ea       	ldi	r24, 0xAA	; 170
    3066:	ce 54       	subi	r28, 0x4E	; 78
    3068:	df 4f       	sbci	r29, 0xFF	; 255
    306a:	88 83       	st	Y, r24
    306c:	c2 5b       	subi	r28, 0xB2	; 178
    306e:	d0 40       	sbci	r29, 0x00	; 0
    3070:	83 ec       	ldi	r24, 0xC3	; 195
    3072:	cd 54       	subi	r28, 0x4D	; 77
    3074:	df 4f       	sbci	r29, 0xFF	; 255
    3076:	88 83       	st	Y, r24
    3078:	c3 5b       	subi	r28, 0xB3	; 179
    307a:	d0 40       	sbci	r29, 0x00	; 0
    307c:	8c e3       	ldi	r24, 0x3C	; 60
    307e:	cc 54       	subi	r28, 0x4C	; 76
    3080:	df 4f       	sbci	r29, 0xFF	; 255
    3082:	88 83       	st	Y, r24
    3084:	c4 5b       	subi	r28, 0xB4	; 180
    3086:	d0 40       	sbci	r29, 0x00	; 0
    3088:	44 e0       	ldi	r20, 0x04	; 4
    308a:	60 e1       	ldi	r22, 0x10	; 16
    308c:	70 e0       	ldi	r23, 0x00	; 0
    308e:	c9 53       	subi	r28, 0x39	; 57
    3090:	df 4f       	sbci	r29, 0xFF	; 255
    3092:	88 81       	ld	r24, Y
    3094:	c7 5c       	subi	r28, 0xC7	; 199
    3096:	d0 40       	sbci	r29, 0x00	; 0
    3098:	c8 53       	subi	r28, 0x38	; 56
    309a:	df 4f       	sbci	r29, 0xFF	; 255
    309c:	98 81       	ld	r25, Y
    309e:	c8 5c       	subi	r28, 0xC8	; 200
    30a0:	d0 40       	sbci	r29, 0x00	; 0
    30a2:	0e 94 ed 05 	call	0xbda	; 0xbda <I2Cbb::write_EE(unsigned char*, unsigned int, unsigned char) [clone .constprop.114]>

[akouz]

When I take the local declaration of the uchar buf4[4] from the function void Mon::reset(void) and make it "global" for the file "HBmonitor.cpp", compiled code changed:

reset():
    303a:	ef e8       	ldi	r30, 0x8F	; 143
    303c:	f8 e6       	ldi	r31, 0x68	; 104
    303e:	14 89       	ldd	r17, Z+20	; 0x14
    3040:	11 30       	cpi	r17, 0x01	; 1
    3042:	81 f5       	brne	.+96     	; 0x30a4 <coos_task_1ms()+0xbba>
    3044:	80 81       	ld	r24, Z
    3046:	91 81       	ldd	r25, Z+1	; 0x01
    3048:	81 30       	cpi	r24, 0x01	; 1
    304a:	91 05       	cpc	r25, r1
    304c:	41 f4       	brne	.+16     	; 0x305e <coos_task_1ms()+0xb74>
    304e:	81 e4       	ldi	r24, 0x41	; 65
    3050:	94 e6       	ldi	r25, 0x64	; 100
    3052:	0e 94 ea 05 	call	0xbd4	; 0xbd4 <I2Cbb::println(char*) [clone .constprop.115]>
    3056:	82 e0       	ldi	r24, 0x02	; 2
    3058:	80 93 9c 6b 	sts	0x6B9C, r24	; 0x806b9c <node+0xb3>
    305c:	2c cd       	rjmp	.-1448   	; 0x2ab6 <coos_task_1ms()+0x5cc>
    305e:	82 30       	cpi	r24, 0x02	; 2
    3060:	91 05       	cpc	r25, r1
    3062:	49 f4       	brne	.+18     	; 0x3076 <coos_task_1ms()+0xb8c>
    3064:	81 e4       	ldi	r24, 0x41	; 65
    3066:	94 e6       	ldi	r25, 0x64	; 100
    3068:	0e 94 ea 05 	call	0xbd4	; 0xbd4 <I2Cbb::println(char*) [clone .constprop.115]>
    306c:	88 ed       	ldi	r24, 0xD8	; 216
    306e:	84 bf       	out	0x34, r24	; 52
    3070:	10 93 41 00 	sts	0x0041, r17	; 0x800041 <__TEXT_REGION_LENGTH__+0x7f0041>
    3074:	20 cd       	rjmp	.-1472   	; 0x2ab6 <coos_task_1ms()+0x5cc>
    3076:	03 97       	sbiw	r24, 0x03	; 3
    3078:	a9 f4       	brne	.+42     	; 0x30a4 <coos_task_1ms()+0xbba>
    307a:	81 e2       	ldi	r24, 0x21	; 33
    307c:	94 e6       	ldi	r25, 0x64	; 100
    307e:	0e 94 ea 05 	call	0xbd4	; 0xbd4 <I2Cbb::println(char*) [clone .constprop.115]>
    3082:	ed e6       	ldi	r30, 0x6D	; 109
    3084:	f6 e6       	ldi	r31, 0x66	; 102
    3086:	85 e5       	ldi	r24, 0x55	; 85
    3088:	80 83       	st	Z, r24
    308a:	8a ea       	ldi	r24, 0xAA	; 170
    308c:	81 83       	std	Z+1, r24	; 0x01
    308e:	83 ec       	ldi	r24, 0xC3	; 195
    3090:	82 83       	std	Z+2, r24	; 0x02
    3092:	8c e3       	ldi	r24, 0x3C	; 60
    3094:	83 83       	std	Z+3, r24	; 0x03
    3096:	44 e0       	ldi	r20, 0x04	; 4
    3098:	60 e1       	ldi	r22, 0x10	; 16
    309a:	70 e0       	ldi	r23, 0x00	; 0
    309c:	cf 01       	movw	r24, r30
    309e:	0e 94 ed 05 	call	0xbda	; 0xbda <I2Cbb::write_EE(unsigned char*, unsigned int, unsigned char) [clone .cons

And behavior of the sketch changed too. Now it correctly writes the pattern into EEPROM, but it corrupts displayed addresses:

[akouz]

I could be wrong, but looking to the listing I conclude that compiler passes parameters to the functions via registers rather than via stack. To the function uchar I2Cbb::write_EE(uchar* buf, uint adrr, uchar len) it passes the pointer uchar* buf via r22 (LSB) and r23 (MSB). In both cases above the correct sequence is evident:
in first case (corrupted pointer)

    308a:	60 e1       	ldi	r22, 0x10	; 16
    308c:	70 e0       	ldi	r23, 0x00	; 0

in second case (correct pointer)

    3098:	60 e1       	ldi	r22, 0x10	; 16
    309a:	70 e0       	ldi	r23, 0x00	; 0

Where r22 could be cleared?

[akouz]

Arduino IDE settings as shown

• When sketch compiled with optimisation for size -Os then sketch more or less works, as discussed above. When buf4 is not local, eerd offset is 2 bytes.
• When the same sketch compiled with optimisation for size -O3 then there is a compiler error:

C:\Users\User\AppData\Local\Temp\cc2x8tK3.s: Assembler messages:
C:\Users\User\AppData\Local\Temp\cc2x8tK3.s:620: Error: symbol `_poll_dre_done' is already defined
C:\Users\User\AppData\Local\Temp\cc2x8tK3.s:883: Error: symbol `_poll_dre_done' is already defined
C:\Users\User\AppData\Local\Temp\cc2x8tK3.s:2320: Error: symbol `_poll_dre_done' is already defined
lto-wrapper.exe: fatal error: C:\Users\User\AppData\Local\Arduino15\packages\DxCore\tools\avr-gcc\7.3.0-atmel3.6.1-azduino6/bin/avr-gcc returned 1 exit status
compilation terminated.

• When the same sketch compiled with optimisation -O2 then sketch behaves almost as per -Os. When buf4 is not local, eerd offset is 1 byte.
• When the same sketch compiled with optimisation -O1 then sketch behaves almost as per -Os When buf4 is not local, eerd offset is 3 bytes.
• When the same sketch compiled with no optimisation -O0 then there is a compiler error:

C:\Users\User\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.5.6\cores\dxcore\wiring_analog.c: In function 'resumeTCD0':
C:\Users\User\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.5.6\cores\dxcore\wiring_analog.c:766:3: error: call to 'badCall' declared with attribute error: 
   badCall("Resuming core control of type D timer not supported.");
   ^
In function 'check_constant_pin',
    inlined from 'digitalWriteFast' at C:\Users\User\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.5.6\cores\dxcore\wiring_digital.c:292:3:
C:\Users\User\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.5.6\cores\dxcore\Arduino.h:424:7: error: call to 'badArg' declared with attribute error: 
       badArg("Fast digital pin must be a constant");
       ^
In function 'check_constant_pin',
    inlined from 'openDrainFast' at C:\Users\User\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.5.6\cores\dxcore\wiring_digital.c:383:3:
C:\Users\User\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.5.6\cores\dxcore\Arduino.h:424:7: error: call to 'badArg' declared with attribute error: 
       badArg("Fast digital pin must be a constant");
       ^
lto-wrapper.exe: fatal error: C:\Users\User\AppData\Local\Arduino15\packages\DxCore\tools\avr-gcc\7.3.0-atmel3.6.1-azduino6/bin/avr-gcc returned 1 exit status
compilation terminated.
c:/users/user/appdata/local/arduino15/packages/dxcore/tools/avr-gcc/7.3.0-atmel3.6.1-azduino6/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld.exe: error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
exit status 1
Error compiling for board HBnode board (AVR64DD32, custom bootloader).

[akouz]

Transition to Arduino 1.8.19 and DxCore 1.5.11 did not make any difference.

[SpenceKonde]

I refer you to

https://gcc.gnu.org/wiki/avr-gcc#Calling_Convention

Whether and which arguments are passed in registers and which are passed on the stack ("in memory") is fully described there.

[akouz]

Thank you. So far I use the following empirical rules:

• do not pass more than 3 arguments to a function
• do not pass a pointer to a function, use a global variable instead
  It is not graceful, but it is sufficient to continue my project rather than wondering to internal guts of C compiler and to disassembled code. If I stuck then I'll use another uC, probably one of Arm family.