Unable to read from Flash using flash_area API even though the bytes are present

I have the following pm_static.yml configuration:

custom_bootloader:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - tfm
  region: flash_primary
  size: 0xc000
custom_bootloader_header:
  address: 0xc000
  end_address: 0xc200
  placement:
    before:
    - tfm
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0xf2000
  region: flash_primary
  orig_span: &id006
  - tfm
  - tfm_nonsecure
  size: 0xE6000
  span: *id006

and I'm trying to acces this `custom_bootloader_header` from my application code. Here's the relevant snippet:

#include <zephyr/storage/flash_map.h>
#include <flash_map_pm.h>



... {

        const struct flash_area *fa;
        printk("custom_bootloader_header: start=%ul, size=%ul\n", fa->fa_off, fa->fa_size);
        flash_area_open(header_flash_area_id, &fa);
        rc = flash_area_read(fa, 0, tags, 256);
        flash_area_close(fa);
}

prj.conf:

CONFIG_FLASH=y
CONFIG_NVS=y

The read function returns `-22`. I can't really do anything with the devicetree because those partitions are ignored when using a static configuration. Not sure what's going on.

Parents Reply Children
  • Hi Andreas,

    From the documentation I understand that "pm_config.h" is automatically imported when I use <flash_map_pm.h> and I also see macros in that file that would use the pm_config.h definitions to return FIXED_PARTITION_ID(custom_bootloader_header).

    Here's the corresponding section in the generated pm_config.h:

    #define PM_CUSTOM_BOOTLOADER_HEADER_OFFSET 0xc000
    #define PM_CUSTOM_BOOTLOADER_HEADER_ADDRESS 0xc000
    #define PM_CUSTOM_BOOTLOADER_HEADER_END_ADDRESS 0xc200
    #define PM_CUSTOM_BOOTLOADER_HEADER_SIZE 0x200
    #define PM_CUSTOM_BOOTLOADER_HEADER_NAME custom_bootloader_header
    #define PM_CUSTOM_BOOTLOADER_HEADER_ID 3
    #define PM_custom_bootloader_header_ID PM_CUSTOM_BOOTLOADER_HEADER_ID
    #define PM_custom_bootloader_header_IS_ENABLED 1
    #define PM_3_LABEL CUSTOM_BOOTLOADER_HEADER
    #define PM_CUSTOM_BOOTLOADER_HEADER_DEV flash_controller
    #define PM_CUSTOM_BOOTLOADER_HEADER_DEFAULT_DRIVER_KCONFIG CONFIG_SOC_FLASH_NRF

    Kind regards,

    Sameer

  • Noted,

    And the results you get with 

      int header_flash_area_id = PM_CUSTOM_BOOTLOADER_HEADER_ID; results in the same error (-22, invalid argument) when calling flash_area_open(header_flash_area_id, &fa);?

    Kind regards,
    Andreas

  • I just tried doing flash_area_open(PM_CUSTOM_BOOTLOADER_HEADER_ID, &fa);

    still observing the same behavior. Please note that flash_area_open returns 0, I get -22 on flash_area_read.

    I also have some debug printing to see the offset and size of the opened flash area: printk("custom_bootloader_header: start=%ul, size=%ul\n", fa->fa_off, fa->fa_size);

    Here's the output (was the same earlier):

    custom_bootloader_header: start=49152, size=512
    flash_area_read rc=-22
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    The offset should be 0xc000 (49152, correct) and size should be 0x200 (512, correct). Below that I do a read and print the first 16 bytes, that are all zero because it's a calloc'd buffer and the -22 return code from the read.

    Kind regards,

    Sameer

  • Hi,

    Sorry for not getting back to you before now. 

    Sameer Srivastava said:
    Please note that flash_area_open returns 0, I get -22 on flash_area_read.

    Good point. 

    What's the "tags" argument you call flash_area_read() with? Does this cause the invalid argument error?

    Kind regards,
    Andreas

  • Hi,

    No problem at all!

    `tags` is just a uint8_t buffer and that's in line with what flash_area_read expects, so I'm not sure if that would be the cause of the issue.

    From what I understand so far, this behavior (reading zeros from flash) could indicate that the region I'm trying to access is protected (even though it doesn't fall under "tfm"). Is there some way for me to verify that? I don't understand why that region would be protected.

    Regards,

    Sameer

Related