Most of my boards are custom made. They are programmed using a 32U4 based custom programmer running the ArduinISP sketch. This has always worked, and still does, with one new angle.
I just made up a new board, after quite a while of no new boards, slightly updated but similar to previous ones based on an Atmega328PB. I uploaded a simple "Blink" like test sketch, using IDE 2.3.5 with MiniCore on Windows 10, as initial check for proper operation and the monitor feedback is as follows:
Sketch uses 1180 bytes (3%) of program storage space. Maximum is 32768 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.
Warning: no eeprom data found in Intel Hex file C:\Users\wille\AppData\Local\arduino\sketches\AD06C6A4CA9F45245C01CBB1FFFCAA91/Decoder_Initial_Test.ino.eep
I have never before seen the warning about an .eep file. Could someone please explain the purpose of the .eep generated file and why it suddenly produces a warning.
Since the sketch is running as expected, implying the board is OK, I assume this warning to not effect the actual upload.
The image generated by the linker can include code, initialized data for SRAM, fuse bytes, and data meant to be written to the EEPROM. That last part can be stored in a separate dot-eep file.
I have no idea why you would get a warning about such a file being missing. EEPROM data is definitely optional.
I just did a quick test and it seems that when I compile for any of my AVR MCUs, with any of my installed cores, a dot-eep file is generated. All these files contain a single line with ":00000001FF". I presume that says it is empty (which causes the above warning during ISP upload)?
Non of the compiles for Zero, UNO R4 WiFi or ESP32 generate a dot-eep file.
I wonder when this started? I have not seen it before (at least not when I last compiled for ISP uploads).
Did an ISP upload with verbose enabled and got the following:
AVR device initialized and ready to accept instructions
Device signature = 1E 95 16 (ATmega328PB)
Auto-erasing chip as flash memory needs programming (-U flash:w:...)
specify the -D option to disable this feature
Erased chip
Processing -U eeprom:w:C:\Users\wille\AppData\Local\arduino\sketches\AD06C6A4CA9F45245C01CBB1FFFCAA91/Decoder_Initial_Test.ino.eep:i
Warning: no eeprom data found in Intel Hex file C:\Users\wille\AppData\Local\arduino\sketches\AD06C6A4CA9F45245C01CBB1FFFCAA91/Decoder_Initial_Test.ino.eep
Reading 0 bytes for eeprom from input file Decoder_Initial_Test.ino.eep
in 0 sections of [0, -1]: 0 pages and 0 pad bytes
Writing 0 bytes to eeprom
Writing | ################################################## | 100% 0.00s
Reading | ################################################## | 100% 0.00s
0 bytes of eeprom verified
Processing -U flash:w:C:\Users\wille\AppData\Local\arduino\sketches\AD06C6A4CA9F45245C01CBB1FFFCAA91/Decoder_Initial_Test.ino.hex:i
Reading 1216 bytes for flash from input file Decoder_Initial_Test.ino.hex
in 1 section [0, 0x4bf]: 10 pages and 64 pad bytes
Writing 1216 bytes to flash
Writing | ################################################## | 100% 0.71s
Reading | ################################################## | 100% 0.37s
1216 bytes of flash verified
Avrdude done. Thank you.
It says it is actually writing (0 bytes) to the EEPROM, now that is a bit stupid. I have "EEPROM retained" selected and wonder if this will mess with the existing data. Will need to check that now.
Reporting just as a means of closure to this tread, should someone have a problem/question re this topic at some future date.
The above write, of zero bytes, and subsequent verify, again of zero bytes, does not effect any data saved to the EEPROM (assuming the "EEPROM retained" was selected). So the warning can safely be ignored under these conditions.
I still feel that the read, verify and warning should not be given with an empty dot-eep file.