Additional read section lets elf2uf2 failing

[dog-rgb]

I added a separate section to the linker script for an external EEPROM. With this I am able to create a hex file with objcopy which can be used to fill this external EEPROM. But the elf2uf2 tool fails with the following error:
[build] ERROR: Memory segment 00000000->00000050 is outside of valid address range for device

The related parts of the linker script looks as follows:

MEMORY
{
    /* Flash starts at offset 64K (size for bootloader)                      */
    FLASH(rx) : ORIGIN = 0x10000000, LENGTH = 1856k     /* without bootloader! */
/*    FLASH(rx) : ORIGIN = 0x10010000, LENGTH = 1856k*/     /* with bootloader! */
    FLASH2(rx) : ORIGIN = 0x101E0000, LENGTH = 128k
    /* RAM reduced by 4 bytes (to ensure those 4 bytes are not overwritten)  */
    RAM(rwx) : ORIGIN =  0x20000000, LENGTH = 262140
    SCRATCH_X(rwx) : ORIGIN = 0x20040000, LENGTH = 4k
    SCRATCH_Y(rwx) : ORIGIN = 0x20041000, LENGTH = 4k
    EEMEM(r)      : ORIGIN = 0x00000000, LENGTH = 32k
}

SECTIONS
{
...
   .eeprom : {
        *(.eeprom)
    } > EEMEM
...
}

The same applies if I use other start address for EEMEM. I haven't found any solution to exclude EEMEM for elf2uf2. As you can see in the linker script, I have also divided the flash into two areas as I need to place data at a specific location (FLASH2) which seems to be included without any problem (which is OK).

[kilograham]

maybe try EEMEM(r!a)

[dog-rgb]

I tried it, unfortunately with the same result, no change.

[kilograham]

out of curiosity why are you putting it in the main linker script - i could understand if it was actually memory mapped at runtime, but it isn't.

[dog-rgb]

I am currently taking over a project from a different microcontroller which has an internal EEPROM area already. The default/initial values are defined in the source code and were extracted to a hex file. So this hex file can be loaded to a fresh EEPROM device or to reset an existing device to the initial state. This section is intended for this purpose only to have one source for an external device and accessing it from the Pico.

I tried to takeover the described concept, but it seems it does not fit to the Pico SDK approach.

Currently I am investigating if I have other possibilities. Fortunately in this project the default values are also available in the flash (to be able to check some version information for compatibility to the program), so I am going to check if I can move these default values to a separate section of the FLASH area (maybe behind the .rodata) instead of having a total new area. With this I think I can still export the default set to a separate hex file and read it from the same place in the running program.

[kilograham]

In which case why are you trying to load it at address 0x00000000

also make sure you do a clean build (blow away your build directory) after messing with the linker scripts - should not be necessary but was with some SDK versions

[dog-rgb]

I found the following solution which works for me. As I stated I need the data also available in the flash. So I finally added a section ".eeprom" which I assigned to the memory "FLASH":

   .eeprom : {
        *(.eeprom)
        . = ALIGN(4);
    } > FLASH

I put this behind .rodata and so I have the content available in flash. With the following command I am able to export the data to fill the EEPROM initially:
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${CMAKE_OBJCOPY} -j .eeprom --change-section-lma .eeprom=0 -Oihex ${PROJECT_NAME}_eeprom.hex)

In my opinion you can close this topic.