EEPROM with new AVR EA CPU

[LaurentR59]

Hi

The EA headers files let show some semantic changes from previous DX header parts ( link too with read write operation change on this most recent parts)

Anyway the current EEPROM file in libraire do not countain the right sentences to compile:

As exemple here is the IOAVR64EA48 header extract

typedef enum NVMCTRL_CMD_enum
{
NVMCTRL_CMD_NOCMD_gc = (0x00<<0), / No Command /
NVMCTRL_CMD_NOOP_gc = (0x01<<0), /* No Operation /
NVMCTRL_CMD_FLPW_gc = (0x04<<0), / Flash Page Write /
NVMCTRL_CMD_FLPERW_gc = (0x05<<0), / Flash Page Erase and Write /
NVMCTRL_CMD_FLPER_gc = (0x08<<0), / Flash Page Erase /
NVMCTRL_CMD_FLMPER2_gc = (0x09<<0), / Flash 2-page erase enable /
NVMCTRL_CMD_FLMPER4_gc = (0x0A<<0), / Flash 4-page erase enable /
NVMCTRL_CMD_FLMPER8_gc = (0x0B<<0), / Flash 8-page erase enable /
NVMCTRL_CMD_FLMPER16_gc = (0x0C<<0), / Flash 16-page erase enable /
NVMCTRL_CMD_FLMPER32_gc = (0x0D<<0), / Flash 32-page erase enable /
NVMCTRL_CMD_FLPBCLR_gc = (0x0F<<0), / Flash Page Buffer Clear /
NVMCTRL_CMD_EEPW_gc = (0x14<<0), / EEPROM Page Write /
NVMCTRL_CMD_EEPERW_gc = (0x15<<0), / EEPROM Page Erase and Write /
NVMCTRL_CMD_EEPER_gc = (0x17<<0), / EEPROM Page Erase /
NVMCTRL_CMD_EEPBCLR_gc = (0x1F<<0), / EEPROM Page Buffer Clear /
NVMCTRL_CMD_CHER_gc = (0x20<<0), / Chip Erase Command (UPDI only) /
NVMCTRL_CMD_EECHER_gc = (0x30<<0) / EEPROM Erase Command (UPDI only) */
} NVMCTRL_CMD_t;

and comparare with IOAVR128DB48 header

typedef enum NVMCTRL_CMD_enum
{
NVMCTRL_CMD_NONE_gc = (0x00<<0), / No Command /
NVMCTRL_CMD_NOOP_gc = (0x01<<0), /* No Operation /
NVMCTRL_CMD_FLWR_gc = (0x02<<0), / Flash Write /
NVMCTRL_CMD_FLPER_gc = (0x08<<0), / Flash Page Erase /
NVMCTRL_CMD_FLMPER2_gc = (0x09<<0), / Flash Multi-Page Erase 2 pages /
NVMCTRL_CMD_FLMPER4_gc = (0x0A<<0), / Flash Multi-Page Erase 4 pages /
NVMCTRL_CMD_FLMPER8_gc = (0x0B<<0), / Flash Multi-Page Erase 8 pages /
NVMCTRL_CMD_FLMPER16_gc = (0x0C<<0), / Flash Multi-Page Erase 16 pages /
NVMCTRL_CMD_FLMPER32_gc = (0x0D<<0), / Flash Multi-Page Erase 32 pages /
NVMCTRL_CMD_EEWR_gc = (0x12<<0), / EEPROM Write /
NVMCTRL_CMD_EEERWR_gc = (0x13<<0), / EEPROM Erase and Write /
NVMCTRL_CMD_EEBER_gc = (0x18<<0), / EEPROM Byte Erase /
NVMCTRL_CMD_EEMBER2_gc = (0x19<<0), / EEPROM Multi-Byte Erase 2 bytes /
NVMCTRL_CMD_EEMBER4_gc = (0x1A<<0), / EEPROM Multi-Byte Erase 4 bytes /
NVMCTRL_CMD_EEMBER8_gc = (0x1B<<0), / EEPROM Multi-Byte Erase 8 bytes /
NVMCTRL_CMD_EEMBER16_gc = (0x1C<<0), / EEPROM Multi-Byte Erase 16 bytes /
NVMCTRL_CMD_EEMBER32_gc = (0x1D<<0), / EEPROM Multi-Byte Erase 32 bytes /
NVMCTRL_CMD_CHER_gc = (0x20<<0), / Chip Erase Command /
NVMCTRL_CMD_EECHER_gc = (0x30<<0) / EEPROM Erase Command */
} NVMCTRL_CMD_t;

So EEPROM only contain instructions for:

while (NVMCTRL.STATUS & NVMCTRL_EEBUSY_bm);
// check at start - not end. Makes writing single bytes fasterms
// Note that we only have interrupts disabled for the dozen or so clock cycles
// during which we start the write, not for the while loop, and we save SREG
// before the while loop. That way there is only a 1 clock window where an
// interrupt that starts a write will cause this write to halt the CPU
// which would cause millis() to lose time.
// Note that writing more than 1 byte in an ISR will always cause millis to lose time.
cli();

_PROTECTED_WRITE_SPM(NVMCTRL.CTRLA, NVMCTRL_CMD_NONE_gc);
_PROTECTED_WRITE_SPM(NVMCTRL.CTRLA, NVMCTRL_CMD_EEERWR_gc);
*(uint8_t *)(MAPPED_EEPROM_START + (index & EEPROM_INDEX_MASK)) = in;

This provide compilation error.

It look like trivious the semantic change of NVMCTRL_CMD_NONE_gc into NVMCTRL_CMD_NOCMD_gc is pretty misconduct habits attitude but about new rows should keep in charge too soon in EEPROM to full support EA parts...

Thanks
Laurent

[SpenceKonde]

This doesn't make much sense to me, do the library examples not compile? Because we should be test compiling all of the eeprom examples for all parts. And tests were passing, so either there is more to this issue, or the examples we have are no good. The solution, for this case (in addition to changing the library to write a 0 instead of a named constant now that microchip has shown themselves to be unreliable about the nvmctrl now, and we expect more chaos in that area since the ea nvm is a shitshow right now (see errata)) is to put in a compatibility define that directs all the names microchip has given them to the right value (same rule is in place about clkctrl too - there have been breaking changes that we dodged several times because I never used the names for selecting the cpu speed since from the start there has been the code to use the outside of spec and undocumented 28 and 32 mhz options (I mean, after verifying that ypu could do every value up to the speced max, and seeing that that was 10 and it was a 4 bit bit field, what would you think the next thing I'd do would be? Obviously, try the next six values!))

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: ***@***.***

On Tue, Sep 26, 2023, 05:35 LaurentR59 ***@***.***> wrote: Hi The EA headers files let show some semantic changes from previous DX header parts ( link too with read write operation change on this most recent parts) Anyway the current EEPROM file in libraire do not countain the right sentences to compile: As exemple here is the IOAVR64EA48 header extract typedef enum NVMCTRL_CMD_enum { *NVMCTRL_CMD_NOCMD_gc = (0x00<<0), / No Command /* NVMCTRL_CMD_NOOP_gc = (0x01<<0), /* No Operation */ NVMCTRL_CMD_FLPW_gc = (0x04<<0), /* Flash Page Write */ NVMCTRL_CMD_FLPERW_gc = (0x05<<0), /* Flash Page Erase and Write */ NVMCTRL_CMD_FLPER_gc = (0x08<<0), /* Flash Page Erase */ NVMCTRL_CMD_FLMPER2_gc = (0x09<<0), /* Flash 2-page erase enable */ NVMCTRL_CMD_FLMPER4_gc = (0x0A<<0), /* Flash 4-page erase enable */ NVMCTRL_CMD_FLMPER8_gc = (0x0B<<0), /* Flash 8-page erase enable */ NVMCTRL_CMD_FLMPER16_gc = (0x0C<<0), /* Flash 16-page erase enable */ NVMCTRL_CMD_FLMPER32_gc = (0x0D<<0), /* Flash 32-page erase enable */ NVMCTRL_CMD_FLPBCLR_gc = (0x0F<<0), /* Flash Page Buffer Clear */ NVMCTRL_CMD_EEPW_gc = (0x14<<0), /* EEPROM Page Write */ NVMCTRL_CMD_EEPERW_gc = (0x15<<0), /* EEPROM Page Erase and Write */ NVMCTRL_CMD_EEPER_gc = (0x17<<0), /* EEPROM Page Erase */ NVMCTRL_CMD_EEPBCLR_gc = (0x1F<<0), /* EEPROM Page Buffer Clear */ NVMCTRL_CMD_CHER_gc = (0x20<<0), /* Chip Erase Command (UPDI only) */ NVMCTRL_CMD_EECHER_gc = (0x30<<0) /* EEPROM Erase Command (UPDI only) */ } NVMCTRL_CMD_t; and comparare with IOAVR128DB48 header typedef enum NVMCTRL_CMD_enum { *NVMCTRL_CMD_NONE_gc = (0x00<<0), / No Command /* NVMCTRL_CMD_NOOP_gc = (0x01<<0), /* No Operation */ NVMCTRL_CMD_FLWR_gc = (0x02<<0), /* Flash Write */ NVMCTRL_CMD_FLPER_gc = (0x08<<0), /* Flash Page Erase */ NVMCTRL_CMD_FLMPER2_gc = (0x09<<0), /* Flash Multi-Page Erase 2 pages */ NVMCTRL_CMD_FLMPER4_gc = (0x0A<<0), /* Flash Multi-Page Erase 4 pages */ NVMCTRL_CMD_FLMPER8_gc = (0x0B<<0), /* Flash Multi-Page Erase 8 pages */ NVMCTRL_CMD_FLMPER16_gc = (0x0C<<0), /* Flash Multi-Page Erase 16 pages */ NVMCTRL_CMD_FLMPER32_gc = (0x0D<<0), /* Flash Multi-Page Erase 32 pages */ NVMCTRL_CMD_EEWR_gc = (0x12<<0), /* EEPROM Write */ NVMCTRL_CMD_EEERWR_gc = (0x13<<0), /* EEPROM Erase and Write */ NVMCTRL_CMD_EEBER_gc = (0x18<<0), /* EEPROM Byte Erase */ NVMCTRL_CMD_EEMBER2_gc = (0x19<<0), /* EEPROM Multi-Byte Erase 2 bytes */ NVMCTRL_CMD_EEMBER4_gc = (0x1A<<0), /* EEPROM Multi-Byte Erase 4 bytes */ NVMCTRL_CMD_EEMBER8_gc = (0x1B<<0), /* EEPROM Multi-Byte Erase 8 bytes */ NVMCTRL_CMD_EEMBER16_gc = (0x1C<<0), /* EEPROM Multi-Byte Erase 16 bytes */ NVMCTRL_CMD_EEMBER32_gc = (0x1D<<0), /* EEPROM Multi-Byte Erase 32 bytes */ NVMCTRL_CMD_CHER_gc = (0x20<<0), /* Chip Erase Command */ NVMCTRL_CMD_EECHER_gc = (0x30<<0) /* EEPROM Erase Command */ } NVMCTRL_CMD_t; So EEPROM only contain instructions for: while (NVMCTRL.STATUS & NVMCTRL_EEBUSY_bm); // check at start - not end. Makes writing single bytes fasterms // Note that we only have interrupts disabled for the dozen or so clock cycles // during which we *start* the write, not for the while loop, and we save SREG // before the while loop. That way there is only a 1 clock window where an // interrupt that starts a write will cause this write to halt the CPU // which would cause millis() to lose time. // Note that writing more than 1 byte in an ISR will *always* cause millis to lose time. cli(); _PROTECTED_WRITE_SPM(NVMCTRL.CTRLA, NVMCTRL_CMD_NONE_gc); _PROTECTED_WRITE_SPM(NVMCTRL.CTRLA, NVMCTRL_CMD_EEERWR_gc); *(uint8_t *)(MAPPED_EEPROM_START + (index & EEPROM_INDEX_MASK)) = in; This provide compilation error. It look like trivious the semantic change of NVMCTRL_CMD_NONE_gc into NVMCTRL_CMD_NOCMD_gc is pretty misconduct habits attitude but about new rows should keep in charge too soon in EEPROM to full support EA parts... Thanks Laurent — Reply to this email directly, view it on GitHub <#482>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW737FACRKWXRDY22OLX4KOX7ANCNFSM6AAAAAA5HNAGBU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[LaurentR59]

Hi Spence

I use now your latest version 1.5.10 in witch one EEPROM have been updated at line#75 (compare to 1.5.8)

#if defined(MEGATINYCORE) || defined(AVR_EA) || defined(AVR_EB) // where parts added: EA & EB CPU

This step fixed my issue so look like perfect right now!

I m able to full compile.

Sorry for warning.

Laurent

[SpenceKonde]

Oh... did I not have CI working on EA for the 1.5.8 release? I don;t think I did. And so the included examples hadn't been compiletested.